vercel-labs/agent-browser

For developers building agents that need to browse and operate real sites, agent-browser is worth a look because it replaces fragile selector guessing with a snapshot-then-click loop. Whether it fits depends on how much you rely on Chrome and how comfortable you are leaving the agent's browser state under the tool's control.

The problem

An agent asked to fill a form or pull data from a web app usually starts by parsing raw HTML and building selectors. That breaks on dynamic pages, hidden overlays and changing markup, and the agent gets no clear signal when a click lands on the wrong element. agent-browser changes the step after page load: it returns an accessibility tree with stable refs, and the agent acts on those refs. The result is a tighter edit-act-observe loop where results come back as page state rather than guessed success.

What's different

The main mechanism is the accessibility snapshot. agent-browser snapshot returns a tree with refs such as @e2, and commands like click @e2 or fill @e3 operate on that reference instead of a CSS selector. Traditional selectors and a role/name finder still work, so existing scripts are not locked out, but the snapshot path is what reduces the agent's need to reason about the DOM.

The CLI also fails clicks early in cases that otherwise look like success: when another element covers the click point, or the element is hidden, disabled or outside the viewport. That gives the agent a concrete error to act on. The same design has a cost: refs are tied to a snapshot, so after the page changes the agent must take a fresh snapshot before retrying. click --new-tab bypasses these checks by opening the link URL directly. The README also lists opt-in security features such as a local encrypted authentication vault, out-of-process plugins and content boundary markers for separating page output from tool output; these are documented capabilities, not independently audited guarantees.

Who should try it

A good fit is an agent developer whose workflow includes logging into web apps, filling multi-step forms or clicking through consent banners and modals, where a snapshot ref is easier to target than a brittle selector. It is also a reasonable choice for a team already running Chrome locally and wanting a native binary rather than a Node-driven browser stack, since the daemon does not require Playwright or Node.js. A poor fit is a team that needs to drive only one fixed browser stack on platforms the CLI does not cover, or one that expects deterministic selectors without a snapshot step. Mobile testing is a separate path: the README documents an Appium-based iOS workflow, including real devices via USB with one-time WebDriverAgent signing, so mobile testers should check that path before committing.

Requirements and limitations

The hard requirement is Chrome. The recommended install is global via npm plus agent-browser install, which downloads Chrome for Testing; existing Chrome, Brave, Playwright and Puppeteer installations are detected automatically. Node.js 24+, pnpm 11+ and Rust are only needed when building from source, so the prebuilt binary path does not require a Node toolchain on the machine.

The recurring upkeep is browser and snapshot management. The agent must re-snapshot after page changes, the Chrome download is a separate first-run step, and handlers like consent banners still need to be dismissed before the original target can be clicked. The iOS simulator and real-device workflows add Appium and, for USB devices, an Apple Developer account for WebDriverAgent signing. See the project instructions and the demo site for setup and feature details.

HotRepo's take

HotRepo recorded 44,540 stars on 2026-10-24 (+49 that day) and 44,545 on 2026-10-25 (+55), with two daily-board appearances in the supplied sample. That is too little comparable history to judge whether interest is rising or fading, and the repository is only 286 days old. Before adopting, verify the snapshot refs behave as expected on the dynamic pages your agent actually targets.