Who agent-browser is for#
AI engineers building multi-step web agents
agent-browser gives an AI agent the full power of a real browser through shell commands: navigate, click, fill forms, take screenshots, and read rendered page content. The ref-based snapshot format keeps context usage low enough to run extended sessions without hitting token limits.
Skip if:
Your agent only needs to fetch static HTML or JSON from APIs. For those workflows, a lightweight HTTP client is simpler and faster than spinning up a browser daemon.
Developers scripting agentic browser workflows in CI
Batch mode lets a CI job run a full browser workflow in a single agent-browser invocation, avoiding per-command process startup. Built-in screenshot diffing and annotated screenshots produce artifacts useful for visual regression checks without a separate testing framework.
Skip if:
You need cross-browser testing across Firefox, WebKit, and Chrome. agent-browser targets Chrome via CDP; Playwright is the better choice when multi-browser coverage is required.
Teams building AI-powered scraping pipelines
The read command fetches agent-readable text from any URL and reads the rendered DOM of an active browser session for pages that require authentication or JavaScript rendering. Sessions carry auth state, so scraping behind a login is a first-class use case.
Skip if:
Your sources serve clean structured data such as RSS, sitemaps, or public REST APIs. agent-browser adds value when you need JavaScript rendering or browser authentication; otherwise a simpler HTTP client is sufficient.
Developers building with WebMCP-enabled pages
WebMCP (experimental) exposes page-provided tools to the CLI and to connected AI agents. Pages that implement the protocol can surface typed tools with schemas that agent-browser discovers automatically and makes available for invocation, turning a web page into a tool server for an agent.
Skip if:
WebMCP is experimental and requires page-side implementation. If the pages you are working with do not implement WebMCP, this feature does not apply.
The problem it solves#
Browser automation for AI agents carries two costs that compound quickly. Full DOM dumps run 3,000-5,000 tokens per page, consuming context budget before the agent completes a single meaningful step. Spawning a fresh browser process for each command adds startup latency that accumulates across multi-step workflows.
Managed cloud browser services avoid the infrastructure burden but introduce per-session pricing, off-premises data handling, and no path to local execution. Running Playwright or Puppeteer gives you more control but produces verbose JSON output designed for JavaScript code, not for LLMs issuing shell commands.
How it solves it#
Ref-based accessibility tree snapshots
The snapshot command returns a compact accessibility tree where every interactive element carries a unique ref like @e1 or @e2. Clicking or filling by ref skips DOM re-querying and points at the exact element from the snapshot, which keeps agent steps deterministic across dynamic pages. Output runs 200-400 tokens per page versus 3,000-5,000 for a full DOM dump.
50+ CLI commands for full browser control
Commands cover navigation, form filling, keyboard input, drag and drop, file upload, screenshots, PDF export, JavaScript eval, clipboard, mouse control, tab and frame management, cookie and storage access, network interception, and debugging. AI agents can script complete multi-step workflows without Playwright or Puppeteer on the caller side.
Client-daemon architecture for fast repeat commands
A native Rust daemon manages Chrome via the Chrome DevTools Protocol and persists between commands. Process startup overhead is paid once per session, not per command. The daemon starts automatically, saves restore state by default, and exits after a configurable idle timeout. Headed browsers, Safari, and user-attached browsers are exempt from the timeout.
Batch command execution
Multiple commands can run in a single CLI invocation, passed as quoted arguments or piped as JSON via stdin. Batch mode avoids per-command process startup for multi-step workflows. Pass --bail to halt on the first error, or let all commands run and inspect results.
Built-in observability tools
Video recording, runtime WebSocket streaming, a profiler, and screenshot diffing are built into the CLI. The annotated screenshot flag adds numbered labels to elements. These tools let you trace agent decisions, compare page states across runs, and debug failed interactions without external tooling.
Stateful sessions with auth and proxy support
Sessions carry profiles, auth state, cookies, storage, and proxy configuration, supporting long-running agents that need to log in once and maintain state across pages. The --restore flag preserves session state between daemon restarts.
Strengths and trade-offs#
Strengths
- Apache-2.0 license with no managed service dependencyThe binary is Apache-2.0 licensed and can run on a developer's laptop, a CI container, or a cloud VM wherever Chrome is available. Unlike Browserbase and Browserless, there is no per-session API pricing and no data leaving your environment. You install the binary and the browser stays local.
- Token-efficient output designed for LLM context budgetsThe snapshot output format was designed specifically for AI context windows. Where a full DOM export costs 3,000-5,000 tokens, a snapshot costs 200-400. Over a multi-step agent workflow that difference compounds. Fewer tokens on browser state means more budget for reasoning, tool calls, and memory.
- Native Rust binaries, no Playwright runtime requiredagent-browser ships as a native binary for macOS (ARM64, x64), Linux (ARM64, x64), and Windows (x64). The Chrome DevTools Protocol daemon is pure Rust with no Node.js runtime dependency after install. Playwright and Puppeteer are not required.
- Compatible with every major AI coding agentWorks with Claude Code, Cursor, GitHub Copilot, OpenAI Codex, Google Gemini, and opencode out of the box. Any agent that can run shell commands can use agent-browser; no SDK or library integration is required.
Trade-offs
- -Chrome required as a runtime dependencyRunning agent-browser requires Chrome, downloaded via agent-browser install from Chrome for Testing on first run. Linux deployments may need system browser libraries installed separately via agent-browser install --with-deps, and this command exits with a non-zero code if the package manager cannot install every required library.
- -High issue volume for a project under a year oldThe repo launched in January 2026 and carries 719 open issues as of September 2026. Active community interest has driven fast feature growth, but the issue backlog also signals accumulating rough edges. Production deployments should pin a release version and test upgrades before rolling out.
- -Parallel sessions require separate daemon instancesThe daemon model is designed for one active browser session per machine. Agents that need many parallel browser sessions across different contexts must run multiple daemon instances on separate machines or containers, which requires infrastructure coordination that a managed cloud browser service handles automatically.
agent-browser vs alternatives#
agent-browser vs Browserbase
Browserbase is a managed cloud browser service built for AI agents. You send commands through its API and Browserbase runs the browser on its infrastructure, billing per session. agent-browser runs the browser locally, controlled entirely through shell commands, with no cloud dependency and Apache-2.0 licensing.
| Feature | agent-browser | Browserbase |
|---|---|---|
| License | Apache-2.0 | Proprietary |
| Deployment | Local / self-hosted | Cloud only |
| Pricing | Free (self-hosted) | Per-session billing |
| Output format | Compact accessibility tree | API response |
| LLM token efficiency | 200-400 tokens per snapshot | Not specified |
agent-browser is the stronger fit when data must stay on your own infrastructure, when per-session API costs grow on high-volume workflows, or when you need the full 50+ command CLI set. Browserbase has the advantage when you need many parallel browser sessions across geographies without managing servers, or when your agent already integrates with its hosted API and you want zero infrastructure responsibility.
agent-browser vs Browserless
Browserless provides a self-hosted or cloud-managed headless Chrome service that exposes a REST and WebSocket API compatible with Puppeteer and Playwright. It targets existing automation tooling that expects an HTTP interface. agent-browser, by contrast, is a first-class CLI. Agents invoke it as shell commands rather than HTTP calls, which makes it a natural fit for coding agents that operate through a terminal or tool-call interface.
| Feature | agent-browser | Browserless |
|---|---|---|
| License | Apache-2.0 | Proprietary |
| Primary interface | CLI | REST / WebSocket API |
| Deployment | Binary install | Docker container |
| Output format | Compact accessibility tree | Standard Playwright output |
| Token efficiency | 200-400 tokens per snapshot | Not optimized for LLMs |
Browserless is the better pick when your existing tooling already speaks Puppeteer or Playwright over HTTP, or when you need standards-compatible automation endpoints. agent-browser is the better pick when you want a purpose-built CLI for LLM-driven workflows, Apache-2.0 licensing, and local execution without running a Docker container.
Quick start#
Install the native binary globally via npm, then run install to download Chrome from Chrome for Testing.
```bash
npm install -g agent-browser
agent-browser install
```What it's built on#
- Languages
- JavaScriptRustTypeScript
- Frameworks
- Next.jsReact
FAQ#
Does agent-browser require Node.js to run?
Node.js is only required when building from source. The distributed npm package contains the native Rust binary; running npm install -g agent-browser installs the binary through npm but the runtime is pure Rust with no ongoing Node.js dependency. You can also install via Homebrew or Cargo without touching Node.js.
Can I use agent-browser with my existing Chrome or Brave installation?
Yes. agent-browser install downloads Chrome from Chrome for Testing by default, but existing Chrome, Brave, Playwright, and Puppeteer installations are detected automatically. You do not need to download a separate browser if a supported one is already present.
How does agent-browser compare to Playwright or Puppeteer for AI agents?
Playwright and Puppeteer expose a JavaScript/TypeScript API that returns verbose DOM data and HTML, typically 3,000-5,000 tokens per page. agent-browser is a CLI designed for agents that issue shell commands: it returns a compact accessibility tree at 200-400 tokens per snapshot. For human-written test automation where a typed API is preferred, Playwright remains the standard choice.
Is agent-browser free to use in commercial projects?
Yes. agent-browser is Apache-2.0 licensed, which permits commercial use, modification, and redistribution. There are no usage fees, no API keys, and no managed service required. You run the binary on your own infrastructure.
Which AI agents and coding assistants work with agent-browser?
Documented integrations include Claude Code, Cursor, GitHub Copilot, OpenAI Codex, Google Gemini, and opencode. Any agent capable of running shell commands can use agent-browser, as the interface is entirely CLI-based with no SDK or library integration required.
Similar open-source tools#
browser
Headless browser for AI agents: 9x faster than Chrome, built in Zig
camofox-browser
Stealth headless browser for AI agents; bypasses bot detection
ego-lite
AI agent browser with shared Chrome state, zero cost
supervision
Python toolkit for computer vision detection, tracking, and annotation
opendisplay
Turn any iPhone, iPad, or spare Mac into a free second Mac monitor
JellyBoxPlayer
Native Jellyfin and Emby music player for every platform