I asked Claude Code to pull model ratings from CivitAI. Simple enough request.
The AI opened a fresh Chrome window. Blank slate. No cookies. No session. Navigated to CivitAI — and hit the Google login button.
It was stuck. Google intentionally blocks OAuth flows from automated browser instances. That's correct behavior from a security standpoint. But for AI browser automation, it was a hard wall.
Chrome 146 just knocked that wall down.
The Root Problem: AI Was Working in an Empty House
Before Chrome 146, the chrome-devtools-mcp server launched Chrome with --user-data-dir pointing to a separate, isolated profile.
That separate profile had nothing in it. No cookies. No saved passwords. No active sessions. Every site you'd ever logged into — GitHub, Google Analytics, CivitAI — required manual re-login every single time.
And for Google OAuth specifically, manual re-login wasn't even an option. Google detects the automated browser fingerprint and blocks the flow outright.
Chrome 136 Made Things Worse
Chrome 136 added another restriction: remote debugging connections to your default profile were blocked entirely.
| Chrome Version | Behavior |
|---|---|
| Up to 135 | Remote debugging to default profile (not recommended but worked) |
| 136–145 | Default profile blocked. --user-data-dir workaround required |
| 146+ (now) |
autoConnect available — AI connects to your actual browser
|
The --user-data-dir workaround was "build a new empty house." autoConnect is "open your front door and let the AI in."
What autoConnect Actually Does
One-sentence version: your AI agent connects to the Chrome instance you're already using.
Enable it at chrome://inspect/#remote-debugging — find the autoConnect toggle under "Discover network targets" and flip it on. That's it.
The next time Claude Code calls chrome-devtools-mcp, it doesn't spawn a new window. It attaches to your running browser. Chrome shows a yellow banner at the top:
Chrome is being controlled by automated test software
Plus a permission dialog: "Allow remote debugging?"
Hit allow, and the AI is now operating your browser — with full access to your existing session, cookies, and logged-in state.
Before vs. After
| Chrome 145 and earlier | Chrome 146 + autoConnect | |
|---|---|---|
| Connects to | Isolated new Chrome profile | Your existing Chrome |
| Cookies | None | Fully inherited |
| Login state | Manual re-login required every time | Already logged in |
| Google OAuth | Blocked | Works (it's your real browser) |
| GitHub | Requires login | Already authenticated |
| CivitAI | Stuck at Google login | Works normally |
| Extensions & settings | None | Your full browser config |
| Security risk | Low (sandboxed) | Higher — AI sees everything |
That last row matters. I'll come back to it.
Setup (Windows-Specific)
Step 1: Confirm Chrome 146
Go to chrome://settings/help. As of March 2026, the current stable is Chrome 146.0.7680.80.
Step 2: Enable autoConnect
- Open
chrome://inspect/#remote-debugging - Find the autoConnect toggle under "Discover network targets"
- Turn it on
Chrome will use port 9222 by default (configurable).
Step 3: Configure chrome-devtools-mcp
Add this to your ~/.claude.json under mcpServers:
{
"mcpServers": {
"chrome-devtools": {
"type": "stdio",
"command": "cmd",
"args": ["/c", "npx", "chrome-devtools-mcp@latest", "--browserUrl=http://localhost:9222"]
}
}
}
The cmd /c wrapper is required on Windows. This is not optional.
If you write "command": "npx" directly, it won't work. Claude Code uses child_process.spawn() internally, and on Windows, npx resolves as npx.cmd — which requires a shell context to execute. Without cmd /c, the process never starts. I hit this exact issue during setup in Tokyo.
Also make sure --browserUrl=http://localhost:9222 is included. Without it, the MCP server doesn't know where to connect.
Step 4: Restart Claude Code
Restart with the MCP enabled. From the next session, you can do things like:
List the top 10 most-downloaded realistic portrait LoRAs on CivitAI,
with ratings and tag counts. Output as a Markdown table.
What You Can Actually Do Now
| Task | Example |
|---|---|
| Browse authenticated sites | CivitAI, GitHub, Google Analytics |
| Fill and submit forms | Applications, contact forms, dashboards |
| Take screenshots | Design review, bug reports |
| Scrape page content | Dashboard data, reports |
| Debug console errors | Read live error logs |
| Run Lighthouse audits | Performance diagnostics |
| Capture memory snapshots | Memory leak investigation |
The Lighthouse integration is worth calling out specifically. You can ask Claude Code to audit a page's performance and get back a full analysis — the AI runs Lighthouse, reads the results, and explains what to fix. No manual tooling required.
The CivitAI Test
I tried it immediately after setup. I asked Claude Code to find the latest realistic portrait LoRAs on CivitAI — top 10, with ratings and comments.
The AI connected to Chrome. Navigated to CivitAI. The Google login button appeared.
It just logged in.
No prompt asking me to handle it manually. No error. It passed through the OAuth flow using my existing Google session — because it was operating my actual browser, not a sandboxed fake.
Five minutes later I had a Markdown table: 10 LoRAs, ratings, comment counts, tags. Previously, that task would have been blocked at the login screen. With autoConnect, it was completely unremarkable.
That's the point. The best automation is the kind that stops being a workaround.
New Features in This Generation
autoConnect isn't the only addition. Here's the full set of new capabilities in the Chrome 146 era of chrome-devtools-mcp:
| Feature | How to use | Purpose |
|---|---|---|
| autoConnect | Toggle in chrome://inspect
|
Connect to your real browser |
| Slim mode |
--slim flag |
Lightweight mode, tab operations only |
| Lighthouse integration | Via MCP automatically | Performance audits |
| Memory snapshots | Via MCP automatically | Memory leak debugging |
| Console log capture | Via MCP automatically | Live error monitoring |
The package is maintained by the official ChromeDevTools team:
- npm:
chrome-devtools-mcp - Official blog:
developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session
Security: Be Honest About the Trade-off
When you enable autoConnect, your AI agent can see everything your browser sees.
That includes:
- Content of every open tab
- Form inputs including passwords
- Session tokens and cookie values
This is a real trade-off, not a theoretical one. My rules for using this safely:
- Enable autoConnect only when you need it. Don't leave it on permanently.
- Disable it when the task is done.
- Close sensitive tabs first — online banking, credit cards, anything you wouldn't show a stranger.
- Only connect trusted agents. Don't point unknown MCP plugins at your real browser session.
You're opening your door to let the AI in. Choose when to open it and who you're letting in.
The Shift This Represents
The --user-data-dir era treated the AI as an external contractor — hand it a temporary badge, a clean desk, and nothing else. Every task started from zero authentication. Google OAuth was a guaranteed failure.
autoConnect treats the AI as a collaborator working alongside you. Same browser, same session, same access. The authentication barrier collapses — not because the security model changed, but because you're explicitly granting access to your own verified session.
The Google OAuth wall was the biggest blocker for practical AI browser automation. Not complex JavaScript rendering, not dynamic SPAs — just the login gate that appears on virtually every useful site.
Chrome 146 solved it. Not with a hack, but with a proper connection model that puts you in control of when and how AI accesses your browser.
That's the right way to do it — and it changes what AI agents can actually accomplish in day-to-day developer workflows.
Top comments (0)