Claude Code can drive a web browser through three different tools. They look similar from the outside but solve different problems. Picking the wrong one wastes time and quietly breaks things, especially when you are working in your own logged-in accounts.
When you ask Claude Code to “test the login flow” or “post this to LinkedIn” or “scrape the documentation,” it has to choose a tool. Behind the scenes, Claude Code has access to three different browser automation primitives. The right choice depends on whether the task needs your real session, how many steps it involves, whether it should run unattended, and how much context budget you are willing to spend.
I learned this trying to get Claude Code to post directly to my LinkedIn. The first tool it picked could not see LinkedIn’s editor in the DOM at all. We burned several rounds of automation before I stopped, audited the three options, and worked out a clean decision rule.
Here it is.
Claude in Chrome (the extension)
Claude in Chrome is a Chrome extension. It attaches to your real browser, the one you are already using, and gives Claude access to all your sessions, cookies, extensions, and login state. When you take a screenshot through Claude in Chrome, you are seeing your actual logged-in account. When you click, you are clicking in your real session.
This is the only one of the three tools that can post to your LinkedIn, send a Gmail draft, manage your Notion pages, or operate your Cloudflare dashboard. Anything behind a login. The real Chrome fingerprint also helps with anti-bot detection systems like Cloudflare and Akamai, which often block headless browsers on sight.
The trade-off: it ties up your actual browser. Long sessions with many actions burn through Claude’s context window because each interaction tends to include a screenshot. And the DOM access can be patchy on heavily framework-driven sites. LinkedIn’s post composer, for example, hides its editor in a way that the extension’s accessibility tree cannot easily reach.
agent-browser (the CLI)
agent-browser is a CLI tool, installed globally via npm. It produces compact accessibility-tree snapshots with element references like @e1, @e2 instead of full DOM dumps. The result is significantly lower token cost than the other two for long browser sessions.
This is what I reach for when testing web apps end-to-end, scraping documentation, or running any task that involves twenty-plus interactions across a flow. The token-efficient output means Claude can keep more context for actual reasoning instead of decoding bloated DOM trees.
The trade-off: it spawns a clean browser. No login state. If your task needs your real account, agent-browser cannot help on its own.
Playwright (via MCP)
Playwright is the headless browser industry standard, exposed to Claude Code through an MCP server. Full DOM access, network inspection, console messages, file uploads, the works. It runs as a separate browser instance, not your real one.
This is the right tool for unattended automation: scheduled scraping, CI-style testing, anything that should run without your Chrome being open. It is also the most powerful option when you need fine-grained DOM control, network debugging, or to run JavaScript inside the page context.
The trade-off is the same as agent-browser. Clean browser, no login state. And the snapshots are verbose, so token cost adds up on long sessions.
The decision rule
| Question | Tool |
|---|---|
| Does the task need my logged-in account? | Claude in Chrome |
| Twenty-plus steps, no auth needed? | agent-browser |
| Should this run unattended or in CI? | Playwright |
| Quick public-site interaction? | Playwright |
| Anti-bot heavy site (Cloudflare, Akamai)? | Claude in Chrome |
In one sentence: Claude in Chrome for your logged-in life, agent-browser for long sessions, Playwright for everything else.
The fallback when the extension wedges
The most useful trick I have picked up: when Claude in Chrome cannot see what you need, fall back to Playwright but attach it to your running Chrome via the Chrome DevTools Protocol on port 9222. Launch Chrome with --remote-debugging-port=9222, and Playwright connects to that running instance instead of spawning its own.
You get Playwright’s full DOM and scripting power, but inside your real authenticated browser. Best of both worlds. This is the path I use when the extension’s accessibility tree cannot reach what I need, like LinkedIn’s post composer.
Real examples from my workflow
Posting to LinkedIn or replying to Gmail in my account: Claude in Chrome. Only it has my session.
Testing a checkout flow on a staging site, twenty clicks deep: agent-browser. Token-efficient and does not need a login.
Scraping competitor pricing pages overnight: Playwright via cron. Unattended, no auth needed.
Cloudflare-protected docs that block headless browsers: Claude in Chrome. The real fingerprint passes.
Filling out a long form in my Notion: Claude in Chrome.
Verifying that a public site renders structured data correctly: Playwright. Fast and isolated.
The cost of picking wrong
Picking the wrong tool is not just an efficiency loss. Using Claude in Chrome for everything ties up your actual browser and can flag accounts if Claude wanders into login walls in random tabs. Using Playwright when you need your real session means Claude is locked out of half your work. Using agent-browser when you need full DOM control leaves you debugging without the right primitives.
The thirty seconds it takes to think “which tool is this task” pays back tenfold in not-broken automation.
Final thought
If you are running Claude Code with browser automation and you have all three tools available, audit your default. Most people end up using one tool out of habit when the other two would do the job better. The decision rule above has held up in my own workflow, and the only escape hatch I have needed so far was the Playwright-on-CDP fallback for the LinkedIn case.
Related
Leave a Reply