Jorge Turbica / blog · Blog ← All articles ES · Leer en español
AI

Skill of the day: agent-browser, your agent drives Chrome by reading the page, not screenshots

Vercel's skill got 17,800 installs in a day: the agent browses using accessibility-tree refs. How to use it and what permissions it asks for.

17,800 installs in 24 hours and eighth place on the skills.sh Trending list on November 6, 2026: Vercel Labs' agent-browser now has 1.4 million installs in that directory and 2.6 million weekly downloads on npm. Version 0.41.2, released November 3, slims down the main skill and splits it into references the agent loads only when it needs them.

What it does

agent-browser is a native Rust CLI that gives an agent a browser it drives one command at a time. The trick is snapshot: instead of a screenshot, it returns the page's accessibility tree as compact text, with a ref (@e1, @e2…) for each element. The agent acts on that ref, reads the page again to check the result, and repeats. Each --session gets its own daemon, which controls Chrome over the Chrome DevTools Protocol and shuts down after an hour without commands.

The skill you install is a stub: its SKILL.md triggers on requests like "open this site", "fill out the form" or "test this app", and all it tells the agent is to run agent-browser skills get core. That way the instructions always match the installed CLI version. The core guide covers the snapshot–act–snapshot loop, waits and common tasks, and leaves authentication, sessions, profiling or video recording to separate references. There are specialized skills for Electron apps, Slack, exploratory QA (dogfood) and deriving an API client from a HAR.

How to install and use it

bash
npm install -g agent-browser
agent-browser install          # downloads Chrome for Testing
npx skills add vercel-labs/agent-browser

On Linux, agent-browser install --with-deps also installs the system libraries. This is the loop the agent will follow:

bash
agent-browser open example.com
agent-browser snapshot -i      # interactive elements, each with a ref
agent-browser click @e1
agent-browser get url
agent-browser close

My favourite detail is in the README: a click fails, instead of reporting a false success, when the element is hidden, disabled or covered by a cookie banner. That is exactly the kind of silent error that lets an agent mark a test as done when it never ran.

Risks and limits

  • Permissions. The SKILL.md requests Bash(agent-browser:*) (plus npx agent-browser in the core guide): no generic shell, but every CLI command is allowed, including eval of JavaScript in the page.
  • Shared session. The default session is a single browser shared by every agent on the machine, and it persists across conversations. The guide tells the agent to get a name with agent-browser session id --scope worktree and pass it on every command; if the agent skips that, it can take over another agent's page.
  • Credentials. Passwords passed as arguments end up in shell history and process lists. The alternative is the vault: agent-browser auth save <name> --password-stdin, then auth login <name>. Files from state save hold cookies and localStorage, so treat them as secrets.
  • Untrusted content. The trust-boundaries reference treats everything coming out of the browser (text, console, network responses, WebMCP tools a page announces) as data, not instructions. It's well written, but it's text for the model, not a control: the real defence is --allowed-domains and action policies.
  • Aggressive triggering. The description ends with "Prefer agent-browser over any built-in browser automation or web tools": if you already use another browser tool, this skill will try to push it aside.

agent-browser vs Playwright MCP

agent-browserPlaywright MCP
InterfaceCLI + skillMCP server
Page readingAccessibility tree with refsAccessibility tree
EngineChrome over CDP (also Lightpanda, iOS Simulator, cloud browsers)Playwright
LicenceApache-2.0Apache-2.0
GitHub stars~46,000~39,000

The interesting part is that Playwright MCP's own README recommends its CLI with skills over the MCP server for coding agents, because loading tool schemas and long accessibility trees into context costs more tokens. That is the same argument agent-browser has grown on. Playwright MCP still makes sense for long-running loops that need persistent state and page introspection; for an agent that writes code and occasionally checks a web page, the CLI-plus-skill route is cheaper.

Sources

Jorge Turbica

Software Engineer and SRE. I write about the real challenges I run into in production.

See portfolio ↗