Browser control shaped for an agent
Most browser automation tools expect a developer to write a program. agent-browser instead turns the useful parts of browser control into small shell commands. An agent opens a page, asks for an accessibility snapshot, receives references such as @e2, then uses those references to click or fill elements. It can also fall back to CSS selectors, text, labels, ARIA roles, or test IDs. This is a better interface for a language model than asking it to repeatedly generate a complete test script.
The accessibility snapshot is the central idea. It gives the model a compact description of actionable page structure rather than raw HTML, and references make the next command short. JSON output supports machine-readable results, while batch execution reduces process startup overhead across several actions. The separate Rust CLI and daemon keep the browser alive between commands, so the shell-oriented design does not require a cold browser launch on every click.
The command surface has grown far beyond navigation. It covers cookies, storage, network routes, HAR capture, screenshots, PDFs, tabs, frames, dialogs, Web Vitals, React inspection, accessibility audits, traces, video, and a live browser preview. The breadth is valuable when an agent needs to diagnose a real application, not merely submit one form. It also raises the learning cost, although the default snapshot workflow remains easy to remember.
Sessions and agent integrations are thoughtfully handled
Multiple named sessions isolate browser instances, cookies, history, and authentication state. Version 0.34.0 added persistent tab binding when sessions share one Chrome connection, plus an optional strict mode that returns a tab_gone error instead of silently adopting another tab. That is a meaningful safeguard for parallel agents, where acting in the wrong tab can be worse than failing. Automatic idle shutdown also limits forgotten background browsers, while restore settings can save state before a daemon exits.
The project speaks to agents through more than its CLI. Bundled skills let supported coding assistants fetch instructions matching the installed version. Claude Code users can install a thin discovery skill, and the README supplies an instruction-file workflow for other assistants. The built-in MCP server exposes typed tools through selectable profiles, so a client can load common browser operations without importing the entire command catalog into context. Because this is an MCP server and a Claude Code skill, those are core product surfaces, not incidental integrations.
Authentication support is practical but deserves care. You can copy a Chrome profile, use a dedicated persistent profile, import state from an attached browser, or save cookies and local storage under a session. State files are plaintext unless the encryption key is configured. Reusing a normal browser through remote debugging also gives any local process powerful access, a risk the README states directly. For team use, dedicated profiles and managed encryption are safer than casually borrowing a developer's everyday session.
Safety features exist, but defaults matter
agent-browser includes domain allowlists, content-boundary markers, output limits, action policies, confirmations, and an encrypted credential vault. The domain control goes beyond top-level navigation by blocking disallowed subresources and disabling WebRTC in supported Chromium sessions. Those are useful controls for an agent consuming untrusted pages.
The catch is explicit in the documentation: these security features are opt-in. An open issue filed on August 11 describes a sharper local risk in version 0.34.0. A repository-level agent-browser.json can specify an executable path or a launch-mutating plugin command, and an ordinary browser command can run that repository-controlled executable without workspace approval. The report requires the user to run agent-browser from the checked-out repository, so cloning alone is not the trigger, but that is still a common coding-agent workflow. Until that behavior gains a trust gate, inspect project configuration before running the tool in unfamiliar code.
Rough edges can stop an unattended run
Two current reports concern failures that do not end cleanly. One shows a snapshot hanging when Chrome's accessibility tree contains a lone UTF-16 surrogate, with flag emoji as a practical trigger. Another shows a page whose main thread never yields leaving the session daemon stuck, with later commands queuing behind CDP timeouts and external process termination needed for recovery. These are unusually detailed reports with reproductions and source-level analysis, not vague complaints.
Other open reports cover a black desktop rectangle after headless Chrome on Windows 11, Chrome discovery missing ~/Applications on macOS, and comma-containing Chromium arguments being split without an escape mechanism. None makes the basic workflow unusable for everyone. Together, they show why unattended production agents need an outer timeout, a process supervisor, a clean session restart path, and tests against the actual target sites.
Health is excellent, stability is still catching up
The repository had more than 40,000 stars and 645 open issues and pull requests on August 11, 2026. It was pushed that day, and release 0.34.0 also arrived that day. Recent work fixed shared-Chrome tab collisions and a doctor command hang, while new reports were receiving active discussion. The large open count reflects both issues and pull requests, and the pace suggests heavy adoption meeting a very young project rather than neglect.
Documentation is exceptional in range. Installation paths, every command group, authentication, security restrictions, MCP profiles, cloud browser providers, serverless use, streaming, iOS setup, and architecture are all covered. The drawback is density: the README has become a manual, so new users should begin with the six-command loop and add features only as needed.
Choose agent-browser when an AI coding assistant needs a compact, inspectable browser interface and shell commands fit the rest of your tooling. Choose Playwright for durable test suites, or a Python agent framework when browser control is only one part of a larger reasoning loop. For interactive and supervised agent work, agent-browser is already one of the strongest options. For autonomous browsing in sensitive environments, treat its safety flags and external recovery as required setup, not optional polish.