Claude Code can now control your Chrome browser. Not a headless session with fresh state. YOUR Chrome, with your cookies and logins already active.
I’ve been using Headless browser agents for migration testing and CI workflows. But those are fresh Playwright sessions: login requires extra steps. Fine for dedicated testing, annoying for ad-hoc work.
Claude in Chrome solves the ad-hoc problem. It opens a new browser window, but shares your Chrome profile: cookies, sessions, logins all intact. Build in terminal, have Claude test in a browser that’s already authenticated everywhere you are, debug with console access, iterate.
Claude can’t just browse anywhere. Before accessing a new domain, you’ll get an approval prompt. This prevents Claude from wandering into your banking site or anywhere else you haven’t explicitly allowed. You control the whitelist per-session.
The Setup
Install the Claude in Chrome extension, then:
claude --chrome
That’s it. Run /chrome to verify connection and configure settings. The extension uses Chrome’s Native Messaging API to receive commands from Claude Code.
Run /chrome and select “Enabled by default” to skip the --chrome flag. The trade-off: Chrome tools are always available, increasing context slightly when invoked. With on-demand loading, the 14k token schema only loads when you actually use browser automation.
The Dev Loop
Here’s what this enables:
Test your local app: “Open localhost:3000, try submitting the form with invalid data, check if error messages appear correctly.”
Debug with console access: “Open the dashboard page and check the console for any errors when the page loads.”
Verify database updates: “Fill out the signup form, submit it, then go to Firebase console and verify the data was saved.”
End-to-end flows: “Test the full checkout flow: add an item to cart, go to checkout, fill payment details, verify confirmation page.”
Claude navigates, clicks, fills forms, scrolls, reads console logs and network requests. You describe the test, Claude executes it.
— Riley Brown (YouTube)It tested the sign-in, signed in with me, filled out the form, submitted it, went to Firebase to verify the data was in the database. It searched the database, found the ID. This is actually insane.
The Killer Feature: Your Session
The game-changer isn’t the automation itself. It’s that Claude uses YOUR browser session.
If you’re logged into Firebase, Claude can navigate to the console and enable authentication providers. If you’re logged into your CRM, Claude can test data entry flows. If you’re logged into internal tools, Claude can verify integrations work.
No credential management. No headless login flows. No separate test accounts. Your existing auth state, accessible to Claude immediately.
This matters for internal tools especially. That admin dashboard behind SSO? Claude can test it. That integration partner’s sandbox? Claude can verify it. Anything you can access in Chrome, Claude can interact with.
What It Can Do
- Navigate and interact: Open URLs, click elements, type text, scroll
- Fill forms: Enter data, select dropdowns, check boxes, submit
- Read state: Console logs, network requests, DOM content, accessibility tree
- Manage tabs: Create, switch, close tabs as needed
- Resize windows: Test responsive layouts
- Record GIFs: Capture test flows as shareable recordings
The recording feature is surprisingly useful. “Record a GIF showing the checkout flow” gives you a visual artifact for documentation or debugging.
Different from Headless
My Headless plugin spawns parallel Playwright agents for automated testing:
/headless:parity https://legacy.example.com https://migrated.example.com
That’s for CI and verification workflows. Parallel agents, fresh sessions, structured comparison reports. Run as part of your dev loop for integration testing, or overnight for regression checks.
Claude in Chrome is the opposite: single session, your auth state, interactive exploration. It’s for the moments when you want to say “test this thing I just built” without writing a test suite.
Use Headless for:
- Migration parity checks
- Regression testing across pages
- Overnight autonomous loops
Use Chrome for:
- Testing features during development
- Debugging issues that need your login
- Quick verification of changes
- Exploring authenticated workflows
Claude in Chrome isn’t headless. It controls a visible browser window. You’ll see it moving around, clicking things. If you need background automation, Headless is still the right tool.
Limitations
This is beta. Some rough edges:
- Modal dialogs block everything. JavaScript alerts, confirms, and prompts freeze browser events. Dismiss them manually, then tell Claude to continue.
- Chrome only. No Brave, Arc, or other Chromium variants yet.
- WSL not supported. Windows users need native Windows, not WSL.
- High-risk sites blocked. Financial services, adult content, and similar categories are off-limits for safety.
The modal issue is the most annoying. If your app triggers an alert(), Claude loses control until you dismiss it. Avoid alert() in code you’re testing, or be ready to intervene.
Ask Claude to create a new tab and retry. Or restart the extension (disable/re-enable). These solve most stuck states.
The Workflow That Works
- Build something in your terminal
- Ask Claude to test it: “Open localhost:3000 and verify the login form validates email format”
- Claude opens your browser, tries invalid input, reports what happened
- You see an issue in the console. “What errors are in the console?”
- Claude reads the console, identifies the problem
- Fix in terminal, repeat
No context switching. No manual browser dance. Build and test in the same session.
I’ve been calling this “closing the dev loop.” You code, Claude verifies, you iterate. The browser becomes an extension of your terminal workflow.
For authentication flows, admin tools, and anything requiring your session state, this is a genuine workflow improvement. For structured testing at scale, stick with Headless. Different tools for different loops.


