| Files | Last commit | Last update |
|---|---|---|
Fix Windows CI - Keep mcp-tools.json line endings as LF so the snapshot test passes on Windows - Use std::env::home_dir so Windows respects USERPROFILE when finding the home directory | 6 days ago | |
Fix Windows CI - Keep mcp-tools.json line endings as LF so the snapshot test passes on Windows - Use std::env::home_dir so Windows respects USERPROFILE when finding the home directory | 6 days ago | |
feat: add `doctor` command for diagnosing installs and cleaning stale daemon state (#1254) * feat: add `doctor` command for install diagnostics and cleanup Adds `agent-browser doctor`, a one-shot diagnostic that checks environment, Chrome install, daemon state, config, encryption key, providers, network reachability, and a live headless launch test. Auto-cleans stale `.sock` / `.pid` / `.version` / `.stream` sidecar files on every run. Destructive repairs (reinstall Chrome, purge old state, close version-mismatched daemons, generate missing encryption key) are gated behind `--fix`. Supports `--offline`, `--quick`, and `--json`. * fixes | 6 months ago | |
Fix Windows CI - Keep mcp-tools.json line endings as LF so the snapshot test passes on Windows - Use std::env::home_dir so Windows respects USERPROFILE when finding the home directory | 6 days ago | |
[cli] Record: require ffmpeg up front, validate output extension (#1778) * feat: require ffmpeg up front for record, validate output extension `record start` depends on ffmpeg for every format, but nothing said so until the first take failed, and a path without an extension only failed at `record stop` with the first 300 chars of stderr (the banner). - Parser rejects output paths with no extension before any daemon call, pointing at .webm/.mp4; the daemon validates too so raw socket callers get the same error, and `record restart` checks the new path before stopping the in-flight take. Paths with any extension are handed to ffmpeg exactly as before (.mkv/.mov/.avi keep working), and `.webm` is now matched case-insensitively when picking libvpx. - ffmpeg failures now report the tail of stderr, where the cause is, and run with -hide_banner. - `doctor` gains a Recording section: ffmpeg on PATH, its version, and whether libvpx and libx264 are compiled in. Warn-level only, since recording is optional. - Document the ffmpeg requirement and the .mp4 option in the docs page, skill files, README, help text, and MCP tool schemas. Closes #1772 * fix: fail record start when ffmpeg is missing, validate the path first ffmpeg was spawned inside the capture task, so with no ffmpeg installed `record start` reported success and the failure only surfaced at `record stop`. It now starts in `start_recording_task` before anything else; on failure the recording state is rolled back and the error is returned from `record start`. If attaching the capture session fails after that, ffmpeg is killed and its empty output removed. Output path validation moves next to the fps check, ahead of the recording context and navigation, in `record start` and `video start`. Two e2e tests: a PATH without ffmpeg fails the start and the next start works; an extensionless path is rejected before any tab is created. * fix: make recording startup rollback safe - Preflight ffmpeg without touching destination files - Roll back capture and stream state on startup failures - Add E2E coverage for data preservation and recording status * fix: preflight ffmpeg before recording mutations - Check ffmpeg before navigation or restart teardown - Preserve active recording state when replacement preflight fails - Add recording E2E coverage for both failure paths * docs: align recording format references - Document WebM and MP4 artifacts across command and streaming pages - Call out the ffmpeg PATH requirement in the command reference --------- Co-authored-by: Chris Tate <chris@ctate.dev> | 2 months ago | |
feat: add `doctor` command for diagnosing installs and cleaning stale daemon state (#1254) * feat: add `doctor` command for install diagnostics and cleanup Adds `agent-browser doctor`, a one-shot diagnostic that checks environment, Chrome install, daemon state, config, encryption key, providers, network reachability, and a live headless launch test. Auto-cleans stale `.sock` / `.pid` / `.version` / `.stream` sidecar files on every run. Destructive repairs (reinstall Chrome, purge old state, close version-mismatched daemons, generate missing encryption key) are gated behind `--fix`. Supports `--offline`, `--quick`, and `--json`. * fixes | 6 months ago | |
[cli] Record: require ffmpeg up front, validate output extension (#1778) * feat: require ffmpeg up front for record, validate output extension `record start` depends on ffmpeg for every format, but nothing said so until the first take failed, and a path without an extension only failed at `record stop` with the first 300 chars of stderr (the banner). - Parser rejects output paths with no extension before any daemon call, pointing at .webm/.mp4; the daemon validates too so raw socket callers get the same error, and `record restart` checks the new path before stopping the in-flight take. Paths with any extension are handed to ffmpeg exactly as before (.mkv/.mov/.avi keep working), and `.webm` is now matched case-insensitively when picking libvpx. - ffmpeg failures now report the tail of stderr, where the cause is, and run with -hide_banner. - `doctor` gains a Recording section: ffmpeg on PATH, its version, and whether libvpx and libx264 are compiled in. Warn-level only, since recording is optional. - Document the ffmpeg requirement and the .mp4 option in the docs page, skill files, README, help text, and MCP tool schemas. Closes #1772 * fix: fail record start when ffmpeg is missing, validate the path first ffmpeg was spawned inside the capture task, so with no ffmpeg installed `record start` reported success and the failure only surfaced at `record stop`. It now starts in `start_recording_task` before anything else; on failure the recording state is rolled back and the error is returned from `record start`. If attaching the capture session fails after that, ffmpeg is killed and its empty output removed. Output path validation moves next to the fps check, ahead of the recording context and navigation, in `record start` and `video start`. Two e2e tests: a PATH without ffmpeg fails the start and the next start works; an extensionless path is rejected before any tab is created. * fix: make recording startup rollback safe - Preflight ffmpeg without touching destination files - Roll back capture and stream state on startup failures - Add E2E coverage for data preservation and recording status * fix: preflight ffmpeg before recording mutations - Check ffmpeg before navigation or restart teardown - Preserve active recording state when replacement preflight fails - Add recording E2E coverage for both failure paths * docs: align recording format references - Document WebM and MP4 artifacts across command and streaming pages - Call out the ffmpeg PATH requirement in the command reference --------- Co-authored-by: Chris Tate <chris@ctate.dev> | 2 months ago | |
feat: send CDP WebSocket headers for generic --cdp URLs (#2005) * feat: send CDP WebSocket headers for generic --cdp URLs Remote browsers such as Cloudflare Browser Rendering authenticate the CDP WebSocket handshake with an Authorization header. Generic --cdp and connect URLs had no way to send one. Add --cdp-headers <json> and AGENT_BROWSER_CDP_HEADERS. Headers must be a JSON object with string values and are passed to connect_cdp_with_headers. Closes #1642 Co-Authored-By: Hariom Sharma <hariom.s2510@gmail.com> * fix(cdp): send CDP headers on discovery and port connects, keep tokens out of errors * fix(cdp): preserve URL scheme on discovery so headers stay encrypted An https:// --cdp URL dropped its scheme before discovery, so /json/version, /json/list and the ws:// fallback sent --cdp-headers credentials over plaintext http/ws, where anyone on the network path could capture them. Thread the input's scheme through discovery: https:// targets probe https:// and wss://, the discovered WebSocket URL is upgraded to wss://, and there is no silent fallback to an unencrypted scheme. http:// URLs and port targets keep plaintext discovery as before. * fix(cdp): keep CDP headers on their origin, reconnect on token change, send them on port connects Discovery only follows same-origin redirects when custom headers are set. CDP headers are part of the launch reuse hash. connect <port> forwards --cdp-headers. * docs(tests): record the --cdp-headers line in the /commands options block * fix(cdp): keep CDP headers when the daemon reconnects on its own A relaunch after close, or one rewritten to the attached target, connected without the headers and failed with 401. The CLI now passes them to the daemon with AGENT_BROWSER_CDP, and a relaunch to the same endpoint reuses the headers of the last explicit launch. --------- Co-authored-by: Hariom Sharma <hariom.s2510@gmail.com> | 9 days ago | |
[cli] Record: require ffmpeg up front, validate output extension (#1778) * feat: require ffmpeg up front for record, validate output extension `record start` depends on ffmpeg for every format, but nothing said so until the first take failed, and a path without an extension only failed at `record stop` with the first 300 chars of stderr (the banner). - Parser rejects output paths with no extension before any daemon call, pointing at .webm/.mp4; the daemon validates too so raw socket callers get the same error, and `record restart` checks the new path before stopping the in-flight take. Paths with any extension are handed to ffmpeg exactly as before (.mkv/.mov/.avi keep working), and `.webm` is now matched case-insensitively when picking libvpx. - ffmpeg failures now report the tail of stderr, where the cause is, and run with -hide_banner. - `doctor` gains a Recording section: ffmpeg on PATH, its version, and whether libvpx and libx264 are compiled in. Warn-level only, since recording is optional. - Document the ffmpeg requirement and the .mp4 option in the docs page, skill files, README, help text, and MCP tool schemas. Closes #1772 * fix: fail record start when ffmpeg is missing, validate the path first ffmpeg was spawned inside the capture task, so with no ffmpeg installed `record start` reported success and the failure only surfaced at `record stop`. It now starts in `start_recording_task` before anything else; on failure the recording state is rolled back and the error is returned from `record start`. If attaching the capture session fails after that, ffmpeg is killed and its empty output removed. Output path validation moves next to the fps check, ahead of the recording context and navigation, in `record start` and `video start`. Two e2e tests: a PATH without ffmpeg fails the start and the next start works; an extensionless path is rejected before any tab is created. * fix: make recording startup rollback safe - Preflight ffmpeg without touching destination files - Roll back capture and stream state on startup failures - Add E2E coverage for data preservation and recording status * fix: preflight ffmpeg before recording mutations - Check ffmpeg before navigation or restart teardown - Preserve active recording state when replacement preflight fails - Add recording E2E coverage for both failure paths * docs: align recording format references - Document WebM and MP4 artifacts across command and streaming pages - Call out the ffmpeg PATH requirement in the command reference --------- Co-authored-by: Chris Tate <chris@ctate.dev> | 2 months ago | |
feat(cli): trust private CAs in CLI HTTPS requests (#2006) * feat(cli): trust private CAs in CLI HTTPS requests read, install, upgrade and doctor verified peers against the compiled-in Mozilla roots only, so a proxy CA deployed by MDM, a sandbox or an enterprise image failed with UnknownIssuer. --ca-cert now adds a CA to these requests on every platform, --use-system-ca selects the OS trust store, and SSL_CERT_FILE is an ambient fallback. Verification stays on. read sends the resolved trust with each request, so the daemon holds no trust state. A command-line selection is saved beside the session until close and survives daemon restarts. --ca-cert on read no longer triggers a browser launch. Co-Authored-By: Bazyli Brzóska <563469+niieani@users.noreply.github.com> * fix(cli): keep the saved CA when a new one fails and trust batched reads * fix(cli): clear saved CA trust when a batch closes the session * test(docs): let the content floor accept inserted lines and declared edits The block-level floor rejected new table rows, new lines inside code blocks, and intentional rewrites of original text, so any docs correction failed. Compare original lines in order instead, and apply rewrites declared in fixtures/docs-edits.json to the live floor. The pinned baseline is unchanged. --------- Co-authored-by: Bazyli Brzóska <563469+niieani@users.noreply.github.com> | 1 month ago | |
feat: add `doctor` command for diagnosing installs and cleaning stale daemon state (#1254) * feat: add `doctor` command for install diagnostics and cleanup Adds `agent-browser doctor`, a one-shot diagnostic that checks environment, Chrome install, daemon state, config, encryption key, providers, network reachability, and a live headless launch test. Auto-cleans stale `.sock` / `.pid` / `.version` / `.stream` sidecar files on every run. Destructive repairs (reinstall Chrome, purge old state, close version-mismatched daemons, generate missing encryption key) are gated behind `--fix`. Supports `--offline`, `--quick`, and `--json`. * fixes | 6 months ago | |
feat: add `doctor` command for diagnosing installs and cleaning stale daemon state (#1254) * feat: add `doctor` command for install diagnostics and cleanup Adds `agent-browser doctor`, a one-shot diagnostic that checks environment, Chrome install, daemon state, config, encryption key, providers, network reachability, and a live headless launch test. Auto-cleans stale `.sock` / `.pid` / `.version` / `.stream` sidecar files on every run. Destructive repairs (reinstall Chrome, purge old state, close version-mismatched daemons, generate missing encryption key) are gated behind `--fix`. Supports `--offline`, `--quick`, and `--json`. * fixes | 6 months ago | |
feat: send CDP WebSocket headers for generic --cdp URLs (#2005) * feat: send CDP WebSocket headers for generic --cdp URLs Remote browsers such as Cloudflare Browser Rendering authenticate the CDP WebSocket handshake with an Authorization header. Generic --cdp and connect URLs had no way to send one. Add --cdp-headers <json> and AGENT_BROWSER_CDP_HEADERS. Headers must be a JSON object with string values and are passed to connect_cdp_with_headers. Closes #1642 Co-Authored-By: Hariom Sharma <hariom.s2510@gmail.com> * fix(cdp): send CDP headers on discovery and port connects, keep tokens out of errors * fix(cdp): preserve URL scheme on discovery so headers stay encrypted An https:// --cdp URL dropped its scheme before discovery, so /json/version, /json/list and the ws:// fallback sent --cdp-headers credentials over plaintext http/ws, where anyone on the network path could capture them. Thread the input's scheme through discovery: https:// targets probe https:// and wss://, the discovered WebSocket URL is upgraded to wss://, and there is no silent fallback to an unencrypted scheme. http:// URLs and port targets keep plaintext discovery as before. * fix(cdp): keep CDP headers on their origin, reconnect on token change, send them on port connects Discovery only follows same-origin redirects when custom headers are set. CDP headers are part of the launch reuse hash. connect <port> forwards --cdp-headers. * docs(tests): record the --cdp-headers line in the /commands options block * fix(cdp): keep CDP headers when the daemon reconnects on its own A relaunch after close, or one rewritten to the attached target, connected without the headers and failed with 401. The CLI now passes them to the daemon with AGENT_BROWSER_CDP, and a relaunch to the same endpoint reuses the headers of the last explicit launch. --------- Co-authored-by: Hariom Sharma <hariom.s2510@gmail.com> | 9 days ago |
| Files | Last commit | Last update |
|---|---|---|
| 6 days ago | ||
| 6 days ago | ||
| 6 months ago | ||
| 6 days ago | ||
| 2 months ago | ||
| 6 months ago | ||
| 2 months ago | ||
| 9 days ago | ||
| 2 months ago | ||
| 1 month ago | ||
| 6 months ago | ||
| 6 months ago | ||
| 9 days ago |