Claude Code Browser Automation: All 5 Ways Compared

The short answer, before anything else: all five routes work, and each breaks somewhere specific. ego (lite) is the pick for daily tasks behind your logins; Claude for Chrome is zero-config but paid and works in the Chrome you're using; Playwright MCP owns testing and CI at a measured 89K-114K tokens per test run; Chrome DevTools MCP owns debugging; agent-browser is fast and token-lean but keeps your logins out.

What earns ego (lite) the first slot: it's the only route that keeps your logins and your window at the same time. The agent works in an isolated Space that inherits your signed-in sessions, whole workflows execute outside the model's context, and it's free.

Every route below works. Every route also has exactly one thing that will eventually make you switch: a paywall, a token bill, a shared window, or a login wall. Knowing yours in advance is the difference between choosing once and choosing three times.

So this guide gives each way four lines: how it works, how to set it up, where it shines, and where it breaks. Then one table, then recommendations by need. All five routes are things we've configured and used; none of the breaking points below is theoretical.

What actually separates the five ways?

Two axes sort all five. First: whose browser does the agent get? Your daily one (with your logins and your focus at stake), or a fresh automation browser (clean, parallel-friendly, and signed out of everything)? Second: how does Claude Code connect? Tool calls through MCP (zero code, but page snapshots flow through your context) or a CLI the agent drives with commands and scripts (code required, context stays lean).

Every route below is one cell of that grid, and the gaps between cells are where switching pressure comes from. Keep the two axes in mind and the five stop blurring together.

What that MCP-versus-CLI split costs on one page

This is a side-by-side of the second axis, not a preview of Way 1 or Way 4. Same Hacker News page, minutes apart today: the MCP snapshot first, then the CLI extraction.

Chrome DevTools MCP take_snapshot

# Chrome DevTools MCP (chrome-devtools-mcp@latest), same page
await session.call_tool("take_snapshot", {})

Real output:
take_snapshot chars: 38285
## Latest page snapshot
uid=1_0 RootWebArea "Hacker News" url="https://news.ycombinator.com/"
  uid=1_1 link url="https://news.ycombinator.com/"
  uid=1_2 link "Hacker News" url="https://news.ycombinator.com/news"
    uid=1_3 StaticText "Hacker News"
  uid=1_4 link "new" url="https://news.ycombinator.com/newest"
    uid=1_5 StaticText "new"
  uid=1_6 StaticText " | "
  uid=1_7 link "past" url="https://news.ycombinator.com/front"
    uid=1_8 StaticText "past"
  uid=1_9 StaticText " | "
  uid=1_10 link "comments" url="https://news.ycombinator.com/newcomments"
    uid=1_11 StaticText "comments"
  uid=1_12 StaticText " | "
  uid=1_13 link "ask" url="https://news.ycombinator.com/ask"
...

ego (lite) via ego-browser, same page

ego-browser nodejs <<'EOF'
const task = await egoBrowser.newTaskSpace('evidence-egobrowser-hn')
console.log({ taskSpaceId: task.id })

await task.page.goto('https://news.ycombinator.com/', { waitUntil: 'load', timeout: 20000 })
const title = await task.page.title()
const topStory = await task.page.locator('.athing .titleline > a').first().innerText()
const points = await task.page.locator('.subtext .score').first().innerText().catch(() => null)
console.log({ title, url: task.page.url(), topStory, points })
EOF

Real output:
{
  "taskSpaceId": 13
}
{
  "title": "Hacker News",
  "url": "https://news.ycombinator.com/",
  "topStory": "Qwen 3.8 27B",
  "points": "412 points"
}

38,285 characters through the model versus about 90 characters of targeted JSON: that's the MCP-versus-CLI cost the axis is naming.

Way 1: ego (lite) via ego-browser

Principle: ego (lite) is an agent browser for browser automation, built for sharing your logged-in browser state with AI agents like Codex or Claude Code. Claude Code writes JavaScript and pipes it through the ego-browser skill; the whole workflow executes in the browser runtime, outside the model's context, inside a Space: an isolated workspace with its own tabs that still inherits your signed-in sessions.

It leads as way 1 because it is ways 2 through 5 combined: the logged-in access the extension route has, and the separate window the protocol routes have. Under the hood, the ego-browser skill drives the browser over CDP, the same protocol ways 4 and 5 speak, pointed at a browser built to be driven instead of the one you're using.

Setup: download ego (lite), finish onboarding (the /ego-browser skill installs into your agent), then just tell your agent what you want. Or skip the manual route entirely: one command from the official repo installs the skill, and one prompt hands the whole setup to the agent you already run.

npx skills add citrolabs/ego-lite

Shines at: daily tasks behind your logins, run in parallel without touching your window, at minimal token cost: our published benchmark measured 44% fewer execution rounds, 35.5% fewer tool calls, and 21.6% lower cost from batching workflows this way, and complex tasks finish up to 3.45x faster than agent-browser, on fewer tokens.

Breaks on: diagnosis and CI. No performance traces or debugging panels (way 4 keeps that job), no headless server mode (it's a desktop browser), and no autonomous navigation: your agent writes the steps.

Way 2: Claude for Chrome

Principle: Anthropic's extension moves Claude into the Chrome you're signed into; from Claude Code you attach it with claude --chrome (or /chrome in a session). Setup: install from the Chrome Web Store, sign in, done; it's in beta on all paid Claude plans.

Shines at: zero-setup tasks inside your accounts (dashboards, mail, CRMs), with the most mature permission system in this list: site-level pre-approvals and confirmation before irreversible actions.

Breaks on: price and possession. It requires a paid plan, serves only Claude, and works in the browser you're using; while it clicks, that window is occupied, and Anthropic's own guidance says to keep it away from financial transactions because prompt-injection defenses "aren't foolproof."

Way 3: Playwright MCP

Principle: Microsoft's MCP server snapshots pages as accessibility trees and executes Claude's chosen actions in a Playwright-managed browser. Setup:

claude mcp add playwright npx '@playwright/mcp@latest'

Shines at: short exploratory sessions, test drafting, cross-browser checks (Firefox, WebKit, Edge), headless CI. Free, Apache-2.0, officially maintained.

Breaks on: tokens and logins. Measured runs put a test at 89K-114K tokens over MCP (a single Salesforce page reached 114K), sessions degrade on stale snapshots around step 12-15, and the browser starts with none of your sessions. The escape routes are its own CLI (27K on the same Microsoft figures) or way 1.

Way 4: Chrome DevTools MCP

Principle: Google's MCP server wraps the DevTools protocol: performance traces with Core Web Vitals, heap snapshots, network inspection, emulation. With --autoConnect (Chrome 144+, remote debugging enabled, permission dialog) it attaches to the Chrome you're signed into. Setup:

claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --autoConnect

Shines at: diagnosis. Why is LCP slow, where's the memory leak, what does this page do on slow 3G: nothing else on this list has these tools at all.

Breaks on: window sharing. Auto-connect puts the agent in your live browser, taking turns with you; great for pair-debugging, wrong for background tasks. Without auto-connect, it's another fresh-profile browser.

Way 5: agent-browser

Principle: Vercel Labs' native Rust CLI (Apache-2.0, ~40K stars): snapshot returns an accessibility tree with refs, then click @e2 style commands act on them; a daemon keeps the browser warm between commands. Setup: npm install -g agent-browser, then agent-browser install to fetch Chrome for Testing.

Shines at: fast, stateless automation: scraping public pages, batch screenshots, CI-adjacent scripting, with sessions deliberately isolated from each other.

Breaks on: login state, by design. Isolated sessions mean your accounts aren't there; users who forced auth state through --profile hit documented fallback-to-blank issues, and cross-origin iframes (Apple ID, Google SSO) are a known blocker.

How do the five compare side by side?

One honesty note before the table: no lab has run all five through one identical task set, so the token column cites each route's own published measurements rather than pretending to a single benchmark.

Which way for which need?

Close by need, since that's how the question actually arrives. Token bill hurting: the CLI family (Playwright's own CLI, agent-browser, or ego-browser scripts); moving execution out of the conversation is the only fix that scales.

Tasks behind your logins: Claude for Chrome if you're paying and don't mind lending your window, ego (lite) if you want the sessions without giving up the window, for free. Parallel tasks while you work: ego (lite) Spaces; it's the only route on this list built for simultaneous isolated tasks.

Debugging and performance: Chrome DevTools MCP, no contest. Official support and testing infrastructure: Playwright MCP, which also remains the right default for CI.

And if you want the two-install setup most daily users land on: ego (lite) for the logged-in task work, DevTools MCP kept lean (--slim) for the day something needs a trace. That pairing covers every column in the table except headless CI, which stays with Playwright proper, where it always belonged.

Download ego (lite) for Mac, free, or start from the browser MCP shortlist for Claude Code if you're set on the MCP route.

FAQ

What's the fastest way to give Claude Code a browser right now?

One command: claude mcp add playwright npx '@playwright/mcp@latest', then ask Claude to "use playwright mcp" to open a page. It's the quickest first browser; whether it's the right long-term one depends on which breaking point above you'll hit first.

Can Claude Code use my logged-in browser without the paid extension?

Yes, two free routes: Chrome DevTools MCP's auto-connect attaches Claude to your signed-in Chrome (sharing your window), and ego (lite) gives it an isolated Space that inherits your sessions without touching your window. The paid extension's remaining edge is pure convenience for non-technical setups.

Do I have to pick just one way?

No, and most working setups don't: the routes register independently and coexist fine. The one real cost of stacking them is context: every enabled MCP server loads its tool schemas into Claude's window, so keep unused servers disabled and enable per task.