Chrome extension: MCP server never connects to native host socket
Description
The claude --chrome MCP server process never connects to the Unix socket created by the Chrome native host, making browser automation tools non-functional in Claude Code. Claude Desktop's Chrome integration works fine with the same extension.
Environment
- Claude Code version: 2.1.80
- OS: macOS Darwin 23.4.0 (Sonoma)
- Chrome extension: Freshly installed from chrome web store
Symptoms
All mcp__claude-in-chrome__* tool calls return:
Browser extension is not connected. Please ensure the Claude browser extension is installed and running...
The MCP server shows as "connected" in /mcp, and tool calls show green dots / "Tabs read" in the UI, but the response content is always the "not connected" error.
Root Cause Investigation
The architecture is:
Chrome Extension → Native Host (stdio) → Unix Socket → MCP Server (claude --chrome)What works:
- Chrome extension spawns the native host correctly
- Native host creates a Unix socket in
/tmp/claude-mcp-browser-bridge-rob/<pid>.sock - MCP server (
claude --chrome) process starts and is reachable from Claude Code
What doesn't work:
- The MCP server has zero socket connections (verified via
lsof -p <pid> | grep sock— empty output) - It never connects to the native host's socket
Reproduction Steps
- Install Chrome extension
- Start Claude Code
- Run any
mcp__claude-in-chrome__*tool (e.g.tabs_context_mcp) - Observe "Browser extension is not connected" error
- Verify with:
```bash
# Find processes
ps aux | grep "chrome-native-host" # Native host - running
ps aux | grep "claude --chrome" # MCP server - running
# Check native host has socket
ls /tmp/claude-mcp-browser-bridge-rob/ # Socket file exists
# Check MCP server socket connections
lsof -p <mcp_server_pid> | grep sock # EMPTY - this is the bug
```
Additional Notes
- Tried clean reinstall: removed all native host configs,
~/.claude/chrome, socket directory, extension, restarted Chrome and Claude Code. Same result. - Claude Desktop's native host (
/Applications/Claude.app/Contents/Helpers/chrome-native-host) works fine with the same extension - When both Desktop and Code native host configs exist, Chrome always picks Desktop's (
com.anthropic.claude_browser_extensionalphabetically beforecom.anthropic.claude_code_browser_extension), which means Code never gets the connection even when Desktop is quit /mcpreconnect restarts the MCP server process but doesn't fix the socket connection issue
13 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Novel idea: fix one of them. This has never worked for me from Claude Code.
Adding corroborating evidence from #37027.
Confirmed Layer 1 issue: When Claude Desktop is installed alongside Claude Code, Desktop's native messaging host (
com.anthropic.claude_browser_extension) intercepts the Chrome extension because it sorts alphabetically before Code's (com.anthropic.claude_code_browser_extension). Renaming Desktop's config fixes this layer — Chrome then correctly spawns Code's native host binary.Layer 2 confirmed identical to your findings: Even after fixing Layer 1,
lsof -Ushows only the native host listener on the socket — zero client connections from Claude Code's MCP. The bridge is architecturally broken.macOS Darwin 25.1.0, Claude Code 2.1.81. Nine concurrent Claude sessions, none connecting to the socket.
This is blocking real workflows. Chrome MCP is a core feature for browser-based testing, form automation, and authenticated page interaction — there's no workaround since Playwright can't access existing Chrome sessions.
6 duplicate issues filed so far (#37027, #36553, #36471, #36159, #34672, #32112) — all reporting the same socket bridge failure. The native host listens, Claude Code's MCP client never connects.
Would appreciate this getting prioritised. Happy to help test a fix.
@claude pls
@claude can yall fix this pls 🧎🏽♂️
For my part, I had just recently set up Claude on GitHub and I think it's swapped my session token for a different kind of token because
/statussaid it was only available for subscription plans. So I re-logged in to Claude Code and when I started it up next it connected to Chrome. It was always using the same account, but somehow that different token that it had saved was blocking it.To this I recommend, log out of both CC and Claude.ai, then login to both again. Just to see if it's the same issue.
Struggling with the issue as well.
Same here — extension shows connected, native host socket never links up. Desktop app on macOS, Chrome 146. Tried creating the native messaging host file manually, restarting Chrome, switching orgs. Nothing works. See #38845 for full details.
not stale
Related issue — CSP violation in Claude for Chrome v1.0.69 breaking Cowork integration
Posting here as this appears to share the same root cause (extension ↔ host connection never established).
Environment
What's happening
The sidepanel.html in v1.0.69 ships with an inline <script> block (dark mode detection, line 8) that violates Chrome's Manifest V3 CSP. This triggers a cascade:
script-src 'self'does not allow unsafe-inlineUncaught (in promise) Error: Could not establish connection. Receiving end does not existAdditional errors observed:
The fix
Chrome's own error output provides the exact hash needed:
sha256-kFwyFWA0myfqRcE5y2d5UX8g0o2QFHSmCz1gWSW0xpk=Either add this hash to
content_security_policyin manifest.json, or move the inline script to a separate .js file.Workarounds attempted (all failed)
Happy to provide screenshots of the full error log from chrome://extensions if helpful.
Thank you for your report — we are currently in the process of triaging MCP-related issues and this one appears to describe the same problem as #24935. To keep the discussion and any fix in one place, we're consolidating into that issue and closing this one. If you have logs, repro steps, or environment details that aren't already covered in #24935, please add them there — it'll help us track this down faster.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.