Browser Automation with Claude Code: A Hands-On 2026 Guide

this tool category moves fast, so verify the latest commands with agent-browser skills get core --full and npx …@latest before you run them.

What is browser automation with Claude Code?

Browser automation with Claude Code means letting the Claude Code agent drive a real browser (navigate, click, fill forms, read the DOM and console, take screenshots, extract data) through a CLI, an MCP server, or an extension - instead of you clicking through everything manually. Put simply, it is AI driving the browser: you describe what you want in plain English, and Claude Code turns that into web actions and runs them for you.

Why do developers need this? A few real situations: running an E2E test on a login flow, filling and submitting a form to check validation, verifying the UI right after you build a component, or scraping a data table to cross-check it. In the past you wrote Playwright or Puppeteer scripts by hand; now Claude Code can build and run those actions itself, then read the results (console logs, DOM structure) and fix itself when something breaks.

If you are new to this tooling, start with what Claude Code is to get comfortable with the ideas of agents and permissions - because browser automation is directly tied to granting an AI the right to act on your behalf.

4 ways for Claude Code to drive a browser (pick the right tool)

The most confusing part is that there are four routes, and the docs for each tool never compare them side by side. Here is a quick map so you choose correctly from the start. Three of the four rely on MCP (Model Context Protocol) - the standard protocol Claude Code uses to connect to external tools.

For most developers, agent-browser is the reasonable default: it is lightweight, token-efficient, and runs for a long time without pulling in the whole Playwright stack. The next three sections dig into installing and using it. You can add Playwright MCP quickly with claude mcp add playwright npx @playwright/mcp@latest, and Chrome DevTools MCP with claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest (per the READMEs for microsoft/playwright-mcp and ChromeDevTools/chrome-devtools-mcp, verified 08/2026).

Installing agent-browser for Claude Code

Setup is fast. agent-browser is an open-source CLI from vercel-labs; the steps below were verified live on 08/09/2026.

# 1. Install the CLI globally
npm install -g agent-browser

# 2. Download the Chromium that agent-browser drives
agent-browser install
# On Linux, if system libraries are missing:
agent-browser install --with-deps

# 3. Confirm the install worked
agent-browser --version

# 4. Load the core workflow set for Claude Code
agent-browser skills get core
# For the full command reference:
agent-browser skills get core --full

Step 4 loads the workflow descriptions so Claude Code knows how to call agent-browser in the right context. Finally, let Claude Code run the command by declaring the allow-tool Bash(agent-browser:*) in your permissions config - otherwise you have to approve each run manually. Update later with agent-browser upgrade.

Step by step: browser automation with Claude Code

The four steps below are the core working loop. The central idea: take a snapshot to get each element's @eN ref, then act through that ref - instead of writing long, brittle CSS selectors.

Step 1 - Open the page and take a snapshot

agent-browser open https://example.com
agent-browser snapshot -i

snapshot -i returns the accessibility tree with short refs like @e1, @e2, and so on for each interactive element. Because each snapshot is only ~280 characters (versus 8K+ for Playwright MCP), Claude Code reads it quickly and burns few tokens - which is exactly why the agent can chain many steps in a row without drowning its context.

Step 2 - Click, fill forms, navigate

# Fill the email field (ref taken from the snapshot)
agent-browser fill @e3 "[email protected]"
# Click the login button
agent-browser click @e7

Always act using refs from the most recent snapshot. An honest caveat: an @eN ref is tied to the current render - if the page changes state (switches tabs, opens a modal, reloads), take a fresh snapshot, because the old ref may now point at the wrong element.

Step 3 - Screenshot and extract data (scrape)

# Save an image of the current state for a visual check
agent-browser screenshot result.png
# Take a snapshot to extract DOM structure and text
agent-browser snapshot -i

From a snapshot, Claude Code can read and summarize content (for example, a product list or a pricing table) into JSON or a Markdown table right there in the terminal.

Step 4 - The self-check loop (build, verify, debug)

This is the most valuable part, and it is the one other guides mention in a single sentence. The flow: you build in the terminal, Claude Code opens the browser to verify the result, reads the console and DOM, and if something is wrong it fixes itself and runs again. Concretely:

1. Claude Code edits the code and starts the dev server.
2. agent-browser open http://localhost:3000 to open the UI you just built.
3. agent-browser snapshot -i to confirm the expected elements appeared; read the console to catch runtime errors.
4. If something is off, Claude Code edits the code, reloads the page, and repeats - until the UI is correct.

This loop is what turns "AI writes code" into "AI verifies its own code in a real browser."

Real-world example: log into a demo site and verify the UI

The demo task: log into a demo site, then confirm the dashboard shows the correct username. Use this as a template you can scale up to real E2E tests.

# Plain-English request you send to Claude Code:
# "Open the demo login page, sign in with the test account,
# then check that the dashboard shows the right name."

agent-browser open https://practice.expandtesting.com/login
agent-browser snapshot -i # get refs for the input fields + button
agent-browser fill @e2 "practice"
agent-browser fill @e3 "SuperSecretPassword!"
agent-browser click @e4 # the Login button
agent-browser snapshot -i # confirm you reached the secure page

An honest note on the experience: the fill and click steps usually run smoothly on simple forms. Where it tends to trip up is a ref going stale after the page changes - after you click Login, the secure page is a new DOM, so you have to run snapshot -i again before verifying; do not reuse refs from the login page. For sites with a captcha or two-factor auth, agent-browser alone is not enough; that is when you need a real logged-in session (see the chrome-profile section below).

Running on cloud and CI/CD (no local browser needed)

When you run inside a CI pipeline or on a machine with no Chrome, you skip installing Chromium locally and point agent-browser at a cloud browser instead:

# Browserbase: set the environment variables, then add the provider with -p
export BROWSERBASE_API_KEY=...
export BROWSERBASE_PROJECT_ID=...
agent-browser -p browserbase open https://example.com

Beyond Browserbase, agent-browser also supports AWS Bedrock AgentCore and Vercel Sandbox for ephemeral environments. To observe running sessions (sessions, logs), agent-browser has an observability dashboard on port 4848. This is the foundation for moving browser tests into an automated pipeline instead of only running them by hand on your dev machine.

agent-browser vs chrome-profile: when do you need real Chrome?

The key decision is this: does the task need a real logged-in session and cookies, or not?

In short: default to agent-browser, and only switch to chrome-profile when you truly have to borrow a real logged-in session - because it acts on your actual account, the risk is higher.

The shortcut - AgentKit ships an ak-agent-browser skill

If you would rather not stand up and configure each tool yourself, there is a shortcut. The AgentKit bundle (Engineer Kit) packages two related skills: ak-agent-browser (which wraps the agent-browser CLI underneath) and ak-chrome-profile - you type a plain-English request and it runs, no memorizing flags.

A note on the name: "AgentKit" here refers to the kit for Claude Code at agentkit.best, which uses the ak CLI - not OpenAI's "AgentKit" product. And agent-browser is the open-source CLI (vercel-labs) sitting underneath this skill.

This is a convenient shortcut, not a requirement: you can absolutely use agent-browser for free exactly as shown in the sections above.

Common errors and how to fix them

Staying safe when you let an AI drive the browser

Handing browser control to an AI opens a real attack surface: prompt injection - malicious content on a web page tricking the agent into doing something you did not intend. According to Anthropic when it announced Claude for Chrome, after adding defenses the prompt injection attack rate dropped from 23.6% to 11.2%, and for a browser-specific class of attacks it fell from 35.7% to 0% on their challenge set (claude.com/blog/claude-for-chrome, 08/2025).

Practical principles for automating safely:

• Grant permissions per site, not globally.
• Require confirmation before high-risk actions: publishing, sending email, sharing data, payments.
• Avoid letting the agent act on its own on pages holding sensitive data or important accounts.
• Prefer a throwaway browser (agent-browser) for tasks that need no login; only use a real session (chrome-profile) when you must.

Frequently asked questions (FAQ)

Is agent-browser or Playwright MCP better?

It depends on what you need. agent-browser is lightweight and token-efficient thanks to compact snapshots (~280 characters vs 8K+ for Playwright MCP), which suits long, autonomous runs. Playwright MCP is strong if you already know the Playwright ecosystem and want many tools ready to go (network, storage, PDF). For most developers, agent-browser is the sensible default.

Do I need to know Playwright?

No. agent-browser is not built on Playwright or Puppeteer; you make plain-English requests and act through @eN refs from the snapshot, without hand-writing Playwright scripts.

Can it run headless / on CI?

Yes. In CI or on a machine with no local browser, point agent-browser at a cloud browser like Browserbase (agent-browser -p browserbase open …), or AWS Bedrock AgentCore, or Vercel Sandbox.

Can it automate pages that are already logged in?

Yes, but you should use chrome-profile to borrow your real logged-in session and cookies. agent-browser runs a throwaway browser by default, which is the right choice when no real account is needed.

Is it safe to let an AI drive the browser?

There is a prompt injection risk, but it is manageable: grant permissions per site, confirm before high-risk actions, and avoid sensitive pages. Vendors have also added defenses that sharply reduce attack rates (see the safety section).

Does AgentKit include this skill?

Yes. The AgentKit bundle (Engineer Kit) ships the ak-agent-browser and ak-chrome-profile skills, which let you skip the manual configuration. It is an optional shortcut, not a requirement for using agent-browser.

Conclusion and next steps

Default to agent-browser: it is lightweight, token-efficient, and runs autonomously well for testing, filling forms, and scraping; switch to chrome-profile only when you need a real logged-in session, and consider Chrome DevTools MCP when you need to measure performance. To understand the protocol layer underneath, read on about what MCP is; to build your own tools for Claude Code, see how to create an MCP server for Claude Code.