Claude-in-Chrome: Extension not connecting despite valid native host and socket

[CharlesHaworth]

Environment

• Claude Code version: 2.1.71 (native install, macOS Darwin 25.3.0, Apple Silicon)
• Chrome: Latest stable
• Claude Desktop: Also installed
• OS: macOS Sequoia

Problem

All mcp__claude-in-chrome__* tools return "Browser extension is not connected" despite the native messaging host running correctly and the Unix domain socket existing.

What works

• Native messaging host manifest is correctly configured at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
• The manifest points to Claude Code's binary: ~/.claude/chrome/chrome-native-host
• The wrapper script executes: ~/.local/share/claude/versions/2.1.71 --chrome-native-host
• Chrome spawns the native host process successfully (confirmed via ps aux)
• Unix socket is created at /tmp/claude-mcp-browser-bridge-charles/<PID>.sock
• Socket accepts connections (confirmed via nc -U)
• claude doctor reports all healthy
• /chrome in Claude Code shows a "reconnect extension" button; clicking it causes Chrome to flash (native host respawns)

What doesn't work

• Claude Code's MCP server never connects to the socket
• mcp__claude-in-chrome__tabs_context_mcp always returns "Browser extension is not connected"
• Tried: restarting Chrome, restarting Claude Code (both --resume and fresh session), killing/respawning the native host, clearing stale sockets

Root cause hypothesis

The Chrome extension hardcodes the native host name com.anthropic.claude_browser_extension (Desktop's host ID), not com.anthropic.claude_code_browser_extension (Code's host ID). We redirected the Desktop manifest to point to Claude Code's binary, which successfully spawns the native host and creates the socket. However, Claude Code's MCP server appears to either:

1. Not scan /tmp/claude-mcp-browser-bridge-charles/ for sockets, or
2. Only scan at startup and miss sockets created afterward, or
3. Use a different communication mechanism entirely that we haven't identified

Steps to reproduce

1. Have both Claude Desktop and Claude Code installed on macOS
2. Install the Claude browser extension in Chrome
3. Start Claude Code with --chrome (or default chrome enabled)
4. Open Chrome
5. Verify native host is running: ps aux | grep chrome-native-host
6. Verify socket exists: ls /tmp/claude-mcp-browser-bridge-charles/
7. Call any mcp__claude-in-chrome__* tool - returns "not connected"

Files checked

~/Library/Application Support/Google/Chrome/NativeMessagingHosts/
  com.anthropic.claude_browser_extension.json      (redirected to Code's binary)
  com.anthropic.claude_code_browser_extension.json (Code's original manifest)
  com.anthropic.claude_browser_extension.json.bak  (Desktop's original manifest)

~/.claude/chrome/chrome-native-host  (wrapper script -> 2.1.71 --chrome-native-host)
/tmp/claude-mcp-browser-bridge-charles/<PID>.sock  (created by native host)

Expected behavior

Claude Code's MCP server should connect to the browser extension socket and mcp__claude-in-chrome__tabs_context_mcp should return tab information.

[CharlesHaworth]

Update: Root cause found via debug logs

Running /debug in Claude Code and reproducing the issue reveals the actual failure:

[Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/<user-id>
[Claude in Chrome] WebSocket connected, sending connect message
[Claude in Chrome] Bridge received: {"type":"error","error":"Invalid token or user mismatch"}
[Claude in Chrome] Bridge error: Invalid token or user mismatch
[Claude in Chrome] Bridge connection closed (code: 1008, duration: 0ms)

Key findings:

1. Claude Code does NOT use the Unix socket (/tmp/claude-mcp-browser-bridge-*/) to connect to the extension. It uses a cloud WebSocket bridge at wss://bridge.claudeusercontent.com/chrome/
2. The native messaging host / Unix socket is only the Chrome-side relay to the bridge
3. The actual failure is authentication — "Invalid token or user mismatch"
4. This likely means the Claude Code OAuth account differs from the account logged into claude.ai in Chrome

Remaining question: The error message "Browser extension is not connected" doesn't surface the actual auth failure to the user, making this very hard to diagnose. Could the error message be improved to show "Invalid token or user mismatch" instead?

The native messaging manifest redirect was unnecessary — the real fix is ensuring matching accounts on both sides.

[github-actions]

Found 3 possible duplicate issues:

1. claude-in-chrome MCP: "Browser extension is not connected" despite native host running correctly via CLI binary #31897
2. Claude Code Chrome integration fails to connect when Claude Desktop (Cowork) is also installed #29057
3. [Bug] Claude in Chrome fails when Claude Desktop native messaging host config exists (macOS) #20316

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[CharlesHaworth]

Update: Continued debugging — still not connecting

After extensive further debugging, the issue persists. Here's everything we've confirmed:

What works

• Native messaging manifest (com.anthropic.claude_browser_extension.json) correctly points to Claude Code's binary at /Users/charles/.claude/chrome/chrome-native-host
• Chrome successfully spawns the native host process: /Users/charles/.local/share/claude/versions/2.1.71 --chrome-native-host
• Unix socket is created at /tmp/claude-mcp-browser-bridge-charles/<PID>.sock
• Socket accepts connections (verified with nc -U)
• Claude Code version (2.1.71) matches the native host binary version

What doesn't work

• Claude Code's built-in chrome MCP server never connects to the socket
• All mcp__claude-in-chrome__* tools return "Browser extension is not connected" or "No Chrome extension connected"

Full list of steps attempted (all failed)

1. Quit Chrome (Cmd+Q), reopened — native host spawned, socket created → still "not connected"
2. Exited Claude Code, restarted with claude --resume → still "not connected"
3. Started fresh Claude Code session (no --resume) → still "not connected"
4. Killed native host, Chrome respawned it → still "not connected"
5. /chrome → "Reconnect Extension" (Chrome flashes, confirming the manifest is being read) → still "not connected"
6. Removed stale socket, restarted Chrome → still "not connected"
7. Ran claude doctor — only checks auto-updater health, no chrome diagnostics
8. Checked /mcp settings dialog → no chrome-specific configuration visible

Hypothesis

The disconnect appears to be between the bridge socket and Claude Code's MCP server. The native host creates the socket successfully, but Claude Code's chrome MCP server either:

• Doesn't scan /tmp/claude-mcp-browser-bridge-charles/ for sockets
• Scans only at startup and misses sockets created afterward
• Fails the handshake silently
• Expects a different socket path or naming convention

Environment

• macOS (Apple Silicon, Darwin 25.3.0)
• Claude Code 2.1.71
• Claude Desktop also installed (but its native host path was redirected to Claude Code's binary)
• Both com.anthropic.claude_browser_extension.json and com.anthropic.claude_code_browser_extension.json manifests exist, both pointing to Claude Code's binary

[CharlesHaworth]

SOLVED: Socket path mismatch

Root Cause

The native host (spawned by Chrome) creates the Unix socket in /tmp/claude-mcp-browser-bridge-<user>/. But Claude Code's MCP server looks for it in $TMPDIR/claude-mcp-browser-bridge-<user>/ — which on macOS resolves to /var/folders/.../T/.

These are different directories. The MCP server never finds the socket.

Fix (two parts)

1. Redirect the native messaging manifest (if Claude Desktop is also installed):

cat > ~/Library/Application\ Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json << 'MANIFEST'
{
  "name": "com.anthropic.claude_browser_extension",
  "description": "Claude Browser Extension Native Host",
  "path": "/Users/<your-user>/.claude/chrome/chrome-native-host",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://dihbgbndebgnbjfmelmegjepbnkhlgni/",
    "chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/",
    "chrome-extension://dngcpimnedloihjnnfngkgjoidhnaolf/"
  ]
}
MANIFEST

2. Symlink the socket directory (the critical fix):

ln -sf /tmp/claude-mcp-browser-bridge-$USER $TMPDIR/claude-mcp-browser-bridge-$USER

This directory-level symlink survives native host PID changes across Chrome restarts.

Then: Restart Chrome, restart Claude Code, and mcp__claude-in-chrome__tabs_context_mcp connects immediately.

Notes

• The tengu_copper_bridge GrowthBook flag was a red herring — it gets overwritten from the server on every startup
• This is the same root cause as [Bug] Claude in Chrome fails when Claude Desktop native messaging host config exists (macOS) #20316
• Confirmed working on Claude Code 2.1.71, macOS Darwin 25.3.0

[cruzlauroiii]

If tengu_copper_bridge is enabled for your account, the MCP server uses BridgeClient (WebSocket) instead of local sockets — even though native host and socket are fine. Workaround: patch _Oz() in cli.js to return;. Full patch with SHA-256 hashes in PR #34789.