3 Ways To Give Claude Code A Browser

Claude Code can open a browser, click around, read pages, and save what it finds without you touching the mouse. There are three ways to hand it a browser, and they look the same until you watch the token bill. In one demo the slowest option took 13 minutes. The fastest did the same job in well under three.

Here are all three, what each is good and bad at, and two questions that tell you which one to pick.

The three options

All three do the same job. What changes is how you hand the browser over to Claude Code.

1. Claude in Chrome (the extension)

This one runs in your real Chrome. It reuses your logins and cookies, so to a website it looks exactly like you, which is good for bot detection. You watch it work in real time in your own browser, and the only setup is adding the plugin. It's the best of the three for debugging your own web apps.

The downsides: it needs a paid Claude plan (no free version), it only supports Chrome and Edge, and it only runs on your machine, so it's no good for a server or a CI/CD pipeline. It also acts inside your logged-in browser, so you're giving it real permissions.

2. Playwright MCP

Think of this one as a separate office with a binder of buttons. Claude gets a list of actions it can call to control the browser: click, list elements, extract data. It's the most mature of the three, built on Playwright, which is the industry standard for testing. If you have repeatable automation or you want to run things in a CI/CD pipeline, this is the one. It can even fake network responses, so you can test how your UI behaves when a request fails.

The catch is tokens. All those commands sit in Claude's memory, and every page it visits gets copied into context, so it burns more tokens than the others. It also doesn't reuse your logins, so some sites flag it as a bot, and if your test needs a login you have to build that part yourself.

3. agent-browser (Vercel)

Think of this one as a walkie-talkie: short and fast. You tell it exactly what to do, it does that one thing, and it hands back only the result. There's no binder loaded into memory, so the context stays clean. It barely touches Claude's memory because it loads an instruction only when it's needed. Ask it to click a button and it loads only the click instruction. It runs headless, but it ships with a live dashboard you can open if you want to watch it work or debug.

The downsides: it's a young project, not as mature as Playwright MCP. It's Chrome only. Because it runs headless it has the same bot-detection issues as Playwright. And since Playwright was built for testing, agent-browser has fewer features.

How to pick

You don't need to memorize all of that. Two questions get you there:

Do you need your own logins, or are you testing your own web app? If yes, use Claude in Chrome.
If no: will it run on a server, or is it a repeatable automation? If yes, use Playwright MCP. If no, use agent-browser.

That's it. Logins or your own app, go Chrome. Server or repeatable, go Playwright. Everyday lookups, agent-browser.

If you'd rather not wire up all three from scratch, I put the two-question cheat-sheet, the setup for each tool, and the exact prompts into a free kit: Claude Code Browser Setup Kit.

The demo

I gave all three the same task to keep it fair. Each one points at Wikipedia's most-popular-articles-of-the-week page, takes the top five articles, opens each one, and saves a digest to a local file with the title, the link, and a two-sentence summary.

Claude in Chrome

Go into the project folder and start Claude with the Chrome flag:

claude --chrome

Check the connection with /chrome. You want the status to say enabled and the extension installed. If not, recheck the plugin and that you're logged in.

Then I gave it the prompt and watched it open Chrome and start working. It struggled. The tab got stuck, it opened a new one, and in the end it fell back to reading the raw wiki text (?action=raw) to pull the data. It got everything I asked for, all five articles with titles, links, and summaries. But it fought the page the whole way, and it took 13 minutes.

Playwright MCP

Open a Claude session in the Playwright folder and have Claude install it for you:

set up the Playwright MCP in this project

Pass it the GitHub link. Once it's done, exit and start a fresh session so the MCP actually loads. You'll see Claude announce a new MCP server in the project, and you can confirm there's a .mcp.json file. Then I gave it the same prompt, saving to a different file so I could compare.

It opened Chrome, navigated to each article in turn, read all five, and wrote the digest. Same output as before, and this time 2 minutes 38 seconds, though it used noticeably more context to get there.

agent-browser

Same idea. Open Claude in the agent-browser folder and have it set things up, including the Claude Code skill so it knows how to use the tool:

set up agent-browser in this project and add its Claude Code skill

This setup is a one-time thing, same as Playwright MCP. After it's done, exit and restart the session so the skill loads. If you want to watch it work, start the dashboard:

agent-browser dashboard start

That opens a live view on localhost:4848. You don't need it, it's just so you can see what's going on. I gave it the same prompt, it opened the page, walked the top five articles, grabbed what it needed, and saved the file. Same result as the other two, clean and fast, and it barely touched Claude's memory.

The verdict

All three got the exact same result. Some took longer and hit a few hiccups, but they all worked. So the question isn't which one is best. It's which one fits the job in front of you.

For this task there was no login, I wasn't testing my own app, and nothing had to run on a server. So agent-browser was the right call. Playwright MCP would have loaded a binder of commands I didn't need, and the extension was the least efficient of the three, taking the longest and burning the most tokens. On a different task, with a login or a CI pipeline, the answer flips.

Links

If you want browser automation built into your team's workflow without the token bill getting out of hand, get in touch. See our AI consulting service for how we work.