{"owner":"vercel-labs","repo":"agent-browser","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nInstructions for AI coding agents working with this codebase.\n\n## Package Manager\n\nThis project uses **pnpm**. Always use `pnpm` instead of `npm` or `yarn` for installing dependencies, running scripts, etc. (e.g., `pnpm install`, `pnpm run build`).\n\n## Code Style\n\n- Do not use emojis in code, output, or documentation. Unicode symbols (✓, ✗, →, ⚠) are acceptable.\n- In documentation and markdown, never use double hyphens (`--`) as a dash. Use an emdash (—) sparingly when needed. Prefer rewriting the sentence to avoid dashes entirely.\n- CLI colored output uses `cli/src/color.rs`. This module respects the `NO_COLOR` environment variable. Never use hardcoded ANSI color codes.\n- CLI flags must always use kebab-case (e.g., `--auto-connect`, `--allow-file-access`). Never use camelCase for flags (e.g., `--autoConnect` is wrong).\n\n## Documentation\n\nDo not hard-wrap prose in documentation files such as Markdown, MDX, and READMEs; let the editor or renderer wrap text naturally.\n\nWhen adding or changing user-facing features (new flags, commands, behaviors, environment variables, etc.), update **all** of the following:\n\n1. `cli/src/output.rs` — `--help` output (flags list, examples, environment variables)\n2. `README.md` — Options table, relevant feature sections, examples\n3. `skill-data/core/SKILL.md` (and its `references/`) — so AI agents know about the feature when they load the core skill. Edit `skill-data/core/SKILL.md` for overview/workflow changes; edit `skill-data/core/references/*.md` for detailed reference content. Do **not** put feature content in `skills/agent-browser/SKILL.md` — that file is an intentionally thin discovery stub for `npx skills add` and exists only to redirect agents to `agent-browser skills get core`.\n4. `docs/src/app/` — the Next.js docs site (MDX pages)\n5. Inline doc comments in the relevant source files\n\nThis applies to changes that either human users or AI agents would need to know about. Do not skip any of these locations.\n\n## CLI/MCP Parity\n\nWhen adding or changing any CLI command, flag, behavior, output, environment variable, or parser semantics, update the MCP server in `cli/src/mcp.rs` in the same change. MCP tools should stay in sync with canonical CLI behavior by delegating through the normal CLI parser where possible. If a CLI command has no dedicated MCP tool, add one or document why it is intentionally omitted. Add or update tests that prove the CLI and MCP surfaces remain aligned.\n\nIn the `docs/src/app/` MDX files, always use HTML `<table>` syntax for tables (not markdown pipe tables). This matches the existing convention across the docs site.\n\n## Dashboard (packages/dashboard)\n\n- Never use native browser dialogs (`alert`, `confirm`, `prompt`). Use shadcn/ui components (`Dialog`, `AlertDialog`, etc.) instead.\n- Use param-case (kebab-case) for all file and folder names (e.g., `session-tree.tsx`, not `SessionTree.tsx`). The `ui/` directory follows shadcn conventions which already uses param-case.\n\n## Releasing\n\nReleases are manual, single-PR affairs. There is no changesets automation. The maintainer controls the changelog voice and format.\n\nTo prepare a release:\n\n1. Create a branch (e.g. `prepare-v0.24.0`)\n2. Bump `version` in `package.json`\n3. Run `pnpm version:sync` to update `cli/Cargo.toml`, `cli/Cargo.lock`, and `packages/dashboard/package.json`\n4. Write the changelog entry in `CHANGELOG.md` at the top, under a new `## <version>` heading, wrapped in `<!-- release:start -->` and `<!-- release:end -->` markers. Remove the `<!-- release:start -->` and `<!-- release:end -->` markers from the previous release entry so only the new release has markers.\n5. Add a matching entry to `docs/src/app/changelog/page.mdx` at the top (below the `# Changelog` heading)\n6. Open a PR and merge to `main`\n\nWhen the PR merges, CI compares `package.json` version to what's on npm. If it differs, it builds all 7 platform binaries, publishes to npm, and creates the GitHub release automatically. The GitHub release body is extracted from the content between the `<!-- release:start -->` and `<!-- release:end -->` markers in `CHANGELOG.md`.\n\n### Writing the changelog\n\nReview the git log since the last release and write the entry in `CHANGELOG.md`. Follow the existing format and voice. Group changes under `### New Features`, `### Bug Fixes`, `### Improvements`, etc. Bold the feature/fix name, then describe it concisely. Reference PR numbers in parentheses.\n\nWrap the release notes (everything between the `## <version>` heading and the previous version) in markers so CI can extract them for the GitHub release. Only the current release should have markers; remove the `<!-- release:start -->` and `<!-- release:end -->` markers from any previous release entry:\n\n```markdown\n## 0.24.1\n\n<!-- release:start -->\n### Bug Fixes\n\n- Fixed **baz** not working when qux is enabled (#1235)\n\n### Contributors\n\n- @ctate\n<!-- release:end -->\n\n## 0.24.0\n\n### New Features\n\n- **Foo command** - Added `foo` command for bar (#1234)\n```\n\nInclude a `### Contributors` section listing the GitHub usernames (with `@` prefix) of everyone who contributed to the release. Check the git log between the previous tag and HEAD to find them.\n\nDo not prefix entries with commit hashes. Do not use the changesets `### Patch Changes` / `### Minor Changes` headings. Use descriptive section names instead.\n\n### Docs changelog\n\nThe docs changelog at `docs/src/app/changelog/page.mdx` mirrors `CHANGELOG.md` but uses a slightly different format. Each entry uses:\n\n- A `v` prefix on the version (e.g. `## v0.24.0`)\n- A date line with the full date: `<p className=\"text-[#888] text-sm\">March 30, 2026</p>`\n- A `---` separator between entries\n\nMatch the existing style in that file.\n\n## Architecture\n\nThis is a Rust codebase. The browser automation daemon lives in `cli/src/native/` (daemon, actions, browser, CDP client, snapshot, state). The `--engine` flag selects Chrome vs Lightpanda. The `install` command downloads Chrome from Chrome for Testing directly.\n\n## Testing\n\n### Unit Tests\n\n```bash\ncd cli && cargo test\n```\n\nRuns all unit tests (~320 tests). These are fast and don't require Chrome.\n\n### End-to-End Tests\n\n```bash\ncd cli && cargo test e2e -- --ignored --test-threads=1\n```\n\nRuns 18 e2e tests that launch real headless Chrome instances and exercise the full native daemon command pipeline. Requirements:\n\n- Chrome must be installed\n- Must run serially (`--test-threads=1`) to avoid Chrome instance contention\n- Tests are `#[ignore]`'d so they don't run during normal `cargo test`\n\nThe e2e tests live in `cli/src/native/e2e_tests.rs` and cover: launch/close, navigation, snapshots, screenshots, form interaction, cookies, storage, tabs, element queries, viewport/emulation, domain filtering, diff, state management, error handling, and Phase 8 commands.\n\n### Linting and Formatting\n\n```bash\ncd cli && cargo fmt -- --check   # Check formatting\ncd cli && cargo clippy            # Lint\n```\n\n## Windows Debugging\n\nA remote Windows Server 2022 EC2 instance is available for debugging Windows-specific issues. It uses AWS Systems Manager (SSM) with no SSH or open ports. Commands run via `aws ssm send-command` and return stdout/stderr.\n\n### Prerequisites\n\nThe instance must be provisioned first (one-time, by a human):\n\n```bash\n./scripts/windows-debug/provision.sh\n```\n\nRequires: AWS CLI v2 configured with `ec2:*`, `iam:CreateRole`, `iam:AttachRolePolicy`, `ssm:SendCommand`, `ssm:GetCommandInvocation` permissions and a default VPC.\n\n### Usage\n\nStart the instance (if stopped):\n\n```bash\n./scripts/windows-debug/start.sh\n```\n\nRun a command on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"<powershell-command>\"\n```\n\nSync the current git branch and rebuild:\n\n```bash\n./scripts/windows-debug/sync.sh\n```\n\nStop the instance when done (avoids cost):\n\n```bash\n./scripts/windows-debug/stop.sh\n```\n\n### Common Workflows\n\nRun unit tests on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"cd C:\\agent-browser && cargo test --manifest-path cli\\Cargo.toml\"\n```\n\nRun e2e tests on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"cd C:\\agent-browser && cargo test e2e --manifest-path cli\\Cargo.toml -- --ignored --test-threads=1\"\n```\n\nCheck bootstrap progress (first boot only):\n\n```bash\n./scripts/windows-debug/run.sh \"Get-Content C:\\bootstrap.log\"\n```\n\nThe repo lives at `C:\\agent-browser` on the instance. Rust, Git, and Chrome are pre-installed. The `run.sh` wrapper automatically adds cargo and git to PATH.\n\n<!-- opensrc:start -->\n\n## Source Code Reference\n\nSource code for dependencies is available in `opensrc/` for deeper understanding of implementation details.\n\nSee `opensrc/sources.json` for the list of available packages and their versions.\n\nUse this source code when you need to understand how a package works internally, not just its types/interface.\n\n### Fetching Additional Source Code\n\nTo fetch source code for a package or repository you need to understand, run:\n\n```bash\nnpx opensrc <package>           # npm package (e.g., npx opensrc zod)\nnpx opensrc pypi:<package>      # Python package (e.g., npx opensrc pypi:requests)\nnpx opensrc crates:<package>    # Rust crate (e.g., npx opensrc crates:serde)\nnpx opensrc <owner>/<repo>      # GitHub repo (e.g., npx opensrc vercel/ai)\n```\n\n<!-- opensrc:end -->\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nInstructions for AI coding agents working with this codebase.\n\n## Package Manager\n\nThis project uses **pnpm**. Always use `pnpm` instead of `npm` or `yarn` for installing dependencies, running scripts, etc. (e.g., `pnpm install`, `pnpm run build`).\n\n## Code Style\n\n- Do not use emojis in code, output, or documentation. Unicode symbols (✓, ✗, →, ⚠) are acceptable.\n- In documentation and markdown, never use double hyphens (`--`) as a dash. Use an emdash (—) sparingly when needed. Prefer rewriting the sentence to avoid dashes entirely.\n- CLI colored output uses `cli/src/color.rs`. This module respects the `NO_COLOR` environment variable. Never use hardcoded ANSI color codes.\n- CLI flags must always use kebab-case (e.g., `--auto-connect`, `--allow-file-access`). Never use camelCase for flags (e.g., `--autoConnect` is wrong).\n\n## Documentation\n\nDo not hard-wrap prose in documentation files such as Markdown, MDX, and READMEs; let the editor or renderer wrap text naturally.\n\nWhen adding or changing user-facing features (new flags, commands, behaviors, environment variables, etc.), update **all** of the following:\n\n1. `cli/src/output.rs` — `--help` output (flags list, examples, environment variables)\n2. `README.md` — Options table, relevant feature sections, examples\n3. `skill-data/core/SKILL.md` (and its `references/`) — so AI agents know about the feature when they load the core skill. Edit `skill-data/core/SKILL.md` for overview/workflow changes; edit `skill-data/core/references/*.md` for detailed reference content. Do **not** put feature content in `skills/agent-browser/SKILL.md` — that file is an intentionally thin discovery stub for `npx skills add` and exists only to redirect agents to `agent-browser skills get core`.\n4. `docs/src/app/` — the Next.js docs site (MDX pages)\n5. Inline doc comments in the relevant source files\n\nThis applies to changes that either human users or AI agents would need to know about. Do not skip any of these locations.\n\n## CLI/MCP Parity\n\nWhen adding or changing any CLI command, flag, behavior, output, environment variable, or parser semantics, update the MCP server in `cli/src/mcp.rs` in the same change. MCP tools should stay in sync with canonical CLI behavior by delegating through the normal CLI parser where possible. If a CLI command has no dedicated MCP tool, add one or document why it is intentionally omitted. Add or update tests that prove the CLI and MCP surfaces remain aligned.\n\nIn the `docs/src/app/` MDX files, always use HTML `<table>` syntax for tables (not markdown pipe tables). This matches the existing convention across the docs site.\n\n## Dashboard (packages/dashboard)\n\n- Never use native browser dialogs (`alert`, `confirm`, `prompt`). Use shadcn/ui components (`Dialog`, `AlertDialog`, etc.) instead.\n- Use param-case (kebab-case) for all file and folder names (e.g., `session-tree.tsx`, not `SessionTree.tsx`). The `ui/` directory follows shadcn conventions which already uses param-case.\n\n## Releasing\n\nReleases are manual, single-PR affairs. There is no changesets automation. The maintainer controls the changelog voice and format.\n\nTo prepare a release:\n\n1. Create a branch (e.g. `prepare-v0.24.0`)\n2. Bump `version` in `package.json`\n3. Run `pnpm version:sync` to update `cli/Cargo.toml`, `cli/Cargo.lock`, and `packages/dashboard/package.json`\n4. Write the changelog entry in `CHANGELOG.md` at the top, under a new `## <version>` heading, wrapped in `<!-- release:start -->` and `<!-- release:end -->` markers. Remove the `<!-- release:start -->` and `<!-- release:end -->` markers from the previous release entry so only the new release has markers.\n5. Add a matching entry to `docs/src/app/changelog/page.mdx` at the top (below the `# Changelog` heading)\n6. Open a PR and merge to `main`\n\nWhen the PR merges, CI compares `package.json` version to what's on npm. If it differs, it builds all 7 platform binaries, publishes to npm, and creates the GitHub release automatically. The GitHub release body is extracted from the content between the `<!-- release:start -->` and `<!-- release:end -->` markers in `CHANGELOG.md`.\n\n### Writing the changelog\n\nReview the git log since the last release and write the entry in `CHANGELOG.md`. Follow the existing format and voice. Group changes under `### New Features`, `### Bug Fixes`, `### Improvements`, etc. Bold the feature/fix name, then describe it concisely. Reference PR numbers in parentheses.\n\nWrap the release notes (everything between the `## <version>` heading and the previous version) in markers so CI can extract them for the GitHub release. Only the current release should have markers; remove the `<!-- release:start -->` and `<!-- release:end -->` markers from any previous release entry:\n\n```markdown\n## 0.24.1\n\n<!-- release:start -->\n### Bug Fixes\n\n- Fixed **baz** not working when qux is enabled (#1235)\n\n### Contributors\n\n- @ctate\n<!-- release:end -->\n\n## 0.24.0\n\n### New Features\n\n- **Foo command** - Added `foo` command for bar (#1234)\n```\n\nInclude a `### Contributors` section listing the GitHub usernames (with `@` prefix) of everyone who contributed to the release. Check the git log between the previous tag and HEAD to find them.\n\nDo not prefix entries with commit hashes. Do not use the changesets `### Patch Changes` / `### Minor Changes` headings. Use descriptive section names instead.\n\n### Docs changelog\n\nThe docs changelog at `docs/src/app/changelog/page.mdx` mirrors `CHANGELOG.md` but uses a slightly different format. Each entry uses:\n\n- A `v` prefix on the version (e.g. `## v0.24.0`)\n- A date line with the full date: `<p className=\"text-[#888] text-sm\">March 30, 2026</p>`\n- A `---` separator between entries\n\nMatch the existing style in that file.\n\n## Architecture\n\nThis is a Rust codebase. The browser automation daemon lives in `cli/src/native/` (daemon, actions, browser, CDP client, snapshot, state). The `--engine` flag selects Chrome vs Lightpanda. The `install` command downloads Chrome from Chrome for Testing directly.\n\n## Testing\n\n### Unit Tests\n\n```bash\ncd cli && cargo test\n```\n\nRuns all unit tests (~320 tests). These are fast and don't require Chrome.\n\n### End-to-End Tests\n\n```bash\ncd cli && cargo test e2e -- --ignored --test-threads=1\n```\n\nRuns 18 e2e tests that launch real headless Chrome instances and exercise the full native daemon command pipeline. Requirements:\n\n- Chrome must be installed\n- Must run serially (`--test-threads=1`) to avoid Chrome instance contention\n- Tests are `#[ignore]`'d so they don't run during normal `cargo test`\n\nThe e2e tests live in `cli/src/native/e2e_tests.rs` and cover: launch/close, navigation, snapshots, screenshots, form interaction, cookies, storage, tabs, element queries, viewport/emulation, domain filtering, diff, state management, error handling, and Phase 8 commands.\n\n### Linting and Formatting\n\n```bash\ncd cli && cargo fmt -- --check   # Check formatting\ncd cli && cargo clippy            # Lint\n```\n\n## Windows Debugging\n\nA remote Windows Server 2022 EC2 instance is available for debugging Windows-specific issues. It uses AWS Systems Manager (SSM) with no SSH or open ports. Commands run via `aws ssm send-command` and return stdout/stderr.\n\n### Prerequisites\n\nThe instance must be provisioned first (one-time, by a human):\n\n```bash\n./scripts/windows-debug/provision.sh\n```\n\nRequires: AWS CLI v2 configured with `ec2:*`, `iam:CreateRole`, `iam:AttachRolePolicy`, `ssm:SendCommand`, `ssm:GetCommandInvocation` permissions and a default VPC.\n\n### Usage\n\nStart the instance (if stopped):\n\n```bash\n./scripts/windows-debug/start.sh\n```\n\nRun a command on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"<powershell-command>\"\n```\n\nSync the current git branch and rebuild:\n\n```bash\n./scripts/windows-debug/sync.sh\n```\n\nStop the instance when done (avoids cost):\n\n```bash\n./scripts/windows-debug/stop.sh\n```\n\n### Common Workflows\n\nRun unit tests on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"cd C:\\agent-browser && cargo test --manifest-path cli\\Cargo.toml\"\n```\n\nRun e2e tests on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"cd C:\\agent-browser && cargo test e2e --manifest-path cli\\Cargo.toml -- --ignored --test-threads=1\"\n```\n\nCheck bootstrap progress (first boot only):\n\n```bash\n./scripts/windows-debug/run.sh \"Get-Content C:\\bootstrap.log\"\n```\n\nThe repo lives at `C:\\agent-browser` on the instance. Rust, Git, and Chrome are pre-installed. The `run.sh` wrapper automatically adds cargo and git to PATH.\n\n<!-- opensrc:start -->\n\n## Source Code Reference\n\nSource code for dependencies is available in `opensrc/` for deeper understanding of implementation details.\n\nSee `opensrc/sources.json` for the list of available packages and their versions.\n\nUse this source code when you need to understand how a package works internally, not just its types/interface.\n\n### Fetching Additional Source Code\n\nTo fetch source code for a package or repository you need to understand, run:\n\n```bash\nnpx opensrc <package>           # npm package (e.g., npx opensrc zod)\nnpx opensrc pypi:<package>      # Python package (e.g., npx opensrc pypi:requests)\nnpx opensrc crates:<package>    # Rust crate (e.g., npx opensrc crates:serde)\nnpx opensrc <owner>/<repo>      # GitHub repo (e.g., npx opensrc vercel/ai)\n```\n\n<!-- opensrc:end -->\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nInstructions for AI coding agents working with this codebase.\n\n## Package Manager\n\nThis project uses **pnpm**. Always use `pnpm` instead of `npm` or `yarn` for installing dependencies, running scripts, etc. (e.g., `pnpm install`, `pnpm run build`).\n\n## Code Style\n\n- Do not use emojis in code, output, or documentation. Unicode symbols (✓, ✗, →, ⚠) are acceptable.\n- In documentation and markdown, never use double hyphens (`--`) as a dash. Use an emdash (—) sparingly when needed. Prefer rewriting the sentence to avoid dashes entirely.\n- CLI colored output uses `cli/src/color.rs`. This module respects the `NO_COLOR` environment variable. Never use hardcoded ANSI color codes.\n- CLI flags must always use kebab-case (e.g., `--auto-connect`, `--allow-file-access`). Never use camelCase for flags (e.g., `--autoConnect` is wrong).\n\n## Documentation\n\nDo not hard-wrap prose in documentation files such as Markdown, MDX, and READMEs; let the editor or renderer wrap text naturally.\n\nWhen adding or changing user-facing features (new flags, commands, behaviors, environment variables, etc.), update **all** of the following:\n\n1. `cli/src/output.rs` — `--help` output (flags list, examples, environment variables)\n2. `README.md` — Options table, relevant feature sections, examples\n3. `skill-data/core/SKILL.md` (and its `references/`) — so AI agents know about the feature when they load the core skill. Edit `skill-data/core/SKILL.md` for overview/workflow changes; edit `skill-data/core/references/*.md` for detailed reference content. Do **not** put feature content in `skills/agent-browser/SKILL.md` — that file is an intentionally thin discovery stub for `npx skills add` and exists only to redirect agents to `agent-browser skills get core`.\n4. `docs/src/app/` — the Next.js docs site (MDX pages)\n5. Inline doc comments in the relevant source files\n\nThis applies to changes that either human users or AI agents would need to know about. Do not skip any of these locations.\n\n## CLI/MCP Parity\n\nWhen adding or changing any CLI command, flag, behavior, output, environment variable, or parser semantics, update the MCP server in `cli/src/mcp.rs` in the same change. MCP tools should stay in sync with canonical CLI behavior by delegating through the normal CLI parser where possible. If a CLI command has no dedicated MCP tool, add one or document why it is intentionally omitted. Add or update tests that prove the CLI and MCP surfaces remain aligned.\n\nIn the `docs/src/app/` MDX files, always use HTML `<table>` syntax for tables (not markdown pipe tables). This matches the existing convention across the docs site.\n\n## Dashboard (packages/dashboard)\n\n- Never use native browser dialogs (`alert`, `confirm`, `prompt`). Use shadcn/ui components (`Dialog`, `AlertDialog`, etc.) instead.\n- Use param-case (kebab-case) for all file and folder names (e.g., `session-tree.tsx`, not `SessionTree.tsx`). The `ui/` directory follows shadcn conventions which already uses param-case.\n\n## Releasing\n\nReleases are manual, single-PR affairs. There is no changesets automation. The maintainer controls the changelog voice and format.\n\nTo prepare a release:\n\n1. Create a branch (e.g. `prepare-v0.24.0`)\n2. Bump `version` in `package.json`\n3. Run `pnpm version:sync` to update `cli/Cargo.toml`, `cli/Cargo.lock`, and `packages/dashboard/package.json`\n4. Write the changelog entry in `CHANGELOG.md` at the top, under a new `## <version>` heading, wrapped in `<!-- release:start -->` and `<!-- release:end -->` markers. Remove the `<!-- release:start -->` and `<!-- release:end -->` markers from the previous release entry so only the new release has markers.\n5. Add a matching entry to `docs/src/app/changelog/page.mdx` at the top (below the `# Changelog` heading)\n6. Open a PR and merge to `main`\n\nWhen the PR merges, CI compares `package.json` version to what's on npm. If it differs, it builds all 7 platform binaries, publishes to npm, and creates the GitHub release automatically. The GitHub release body is extracted from the content between the `<!-- release:start -->` and `<!-- release:end -->` markers in `CHANGELOG.md`.\n\n### Writing the changelog\n\nReview the git log since the last release and write the entry in `CHANGELOG.md`. Follow the existing format and voice. Group changes under `### New Features`, `### Bug Fixes`, `### Improvements`, etc. Bold the feature/fix name, then describe it concisely. Reference PR numbers in parentheses.\n\nWrap the release notes (everything between the `## <version>` heading and the previous version) in markers so CI can extract them for the GitHub release. Only the current release should have markers; remove the `<!-- release:start -->` and `<!-- release:end -->` markers from any previous release entry:\n\n```markdown\n## 0.24.1\n\n<!-- release:start -->\n### Bug Fixes\n\n- Fixed **baz** not working when qux is enabled (#1235)\n\n### Contributors\n\n- @ctate\n<!-- release:end -->\n\n## 0.24.0\n\n### New Features\n\n- **Foo command** - Added `foo` command for bar (#1234)\n```\n\nInclude a `### Contributors` section listing the GitHub usernames (with `@` prefix) of everyone who contributed to the release. Check the git log between the previous tag and HEAD to find them.\n\nDo not prefix entries with commit hashes. Do not use the changesets `### Patch Changes` / `### Minor Changes` headings. Use descriptive section names instead.\n\n### Docs changelog\n\nThe docs changelog at `docs/src/app/changelog/page.mdx` mirrors `CHANGELOG.md` but uses a slightly different format. Each entry uses:\n\n- A `v` prefix on the version (e.g. `## v0.24.0`)\n- A date line with the full date: `<p className=\"text-[#888] text-sm\">March 30, 2026</p>`\n- A `---` separator between entries\n\nMatch the existing style in that file.\n\n## Architecture\n\nThis is a Rust codebase. The browser automation daemon lives in `cli/src/native/` (daemon, actions, browser, CDP client, snapshot, state). The `--engine` flag selects Chrome vs Lightpanda. The `install` command downloads Chrome from Chrome for Testing directly.\n\n## Testing\n\n### Unit Tests\n\n```bash\ncd cli && cargo test\n```\n\nRuns all unit tests (~320 tests). These are fast and don't require Chrome.\n\n### End-to-End Tests\n\n```bash\ncd cli && cargo test e2e -- --ignored --test-threads=1\n```\n\nRuns 18 e2e tests that launch real headless Chrome instances and exercise the full native daemon command pipeline. Requirements:\n\n- Chrome must be installed\n- Must run serially (`--test-threads=1`) to avoid Chrome instance contention\n- Tests are `#[ignore]`'d so they don't run during normal `cargo test`\n\nThe e2e tests live in `cli/src/native/e2e_tests.rs` and cover: launch/close, navigation, snapshots, screenshots, form interaction, cookies, storage, tabs, element queries, viewport/emulation, domain filtering, diff, state management, error handling, and Phase 8 commands.\n\n### Linting and Formatting\n\n```bash\ncd cli && cargo fmt -- --check   # Check formatting\ncd cli && cargo clippy            # Lint\n```\n\n## Windows Debugging\n\nA remote Windows Server 2022 EC2 instance is available for debugging Windows-specific issues. It uses AWS Systems Manager (SSM) with no SSH or open ports. Commands run via `aws ssm send-command` and return stdout/stderr.\n\n### Prerequisites\n\nThe instance must be provisioned first (one-time, by a human):\n\n```bash\n./scripts/windows-debug/provision.sh\n```\n\nRequires: AWS CLI v2 configured with `ec2:*`, `iam:CreateRole`, `iam:AttachRolePolicy`, `ssm:SendCommand`, `ssm:GetCommandInvocation` permissions and a default VPC.\n\n### Usage\n\nStart the instance (if stopped):\n\n```bash\n./scripts/windows-debug/start.sh\n```\n\nRun a command on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"<powershell-command>\"\n```\n\nSync the current git branch and rebuild:\n\n```bash\n./scripts/windows-debug/sync.sh\n```\n\nStop the instance when done (avoids cost):\n\n```bash\n./scripts/windows-debug/stop.sh\n```\n\n### Common Workflows\n\nRun unit tests on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"cd C:\\agent-browser && cargo test --manifest-path cli\\Cargo.toml\"\n```\n\nRun e2e tests on Windows:\n\n```bash\n./scripts/windows-debug/run.sh \"cd C:\\agent-browser && cargo test e2e --manifest-path cli\\Cargo.toml -- --ignored --test-threads=1\"\n```\n\nCheck bootstrap progress (first boot only):\n\n```bash\n./scripts/windows-debug/run.sh \"Get-Content C:\\bootstrap.log\"\n```\n\nThe repo lives at `C:\\agent-browser` on the instance. Rust, Git, and Chrome are pre-installed. The `run.sh` wrapper automatically adds cargo and git to PATH.\n\n<!-- opensrc:start -->\n\n## Source Code Reference\n\nSource code for dependencies is available in `opensrc/` for deeper understanding of implementation details.\n\nSee `opensrc/sources.json` for the list of available packages and their versions.\n\nUse this source code when you need to understand how a package works internally, not just its types/interface.\n\n### Fetching Additional Source Code\n\nTo fetch source code for a package or repository you need to understand, run:\n\n```bash\nnpx opensrc <package>           # npm package (e.g., npx opensrc zod)\nnpx opensrc pypi:<package>      # Python package (e.g., npx opensrc pypi:requests)\nnpx opensrc crates:<package>    # Rust crate (e.g., npx opensrc crates:serde)\nnpx opensrc <owner>/<repo>      # GitHub repo (e.g., npx opensrc vercel/ai)\n```\n\n<!-- opensrc:end -->\n","category":"root","tokens":2323}]}