claude-code - 💡(How to fix) Fix claude-in-chrome: MCP shows connected but extension bridge fails (native host listening, Claude Code never connects to bridge socket) [1 comments, 2 participants]

Summary

claude-in-chrome MCP server reports as connected with 20 tools available, but every tool call returns "Browser extension is not connected." The Chrome extension is installed and active, the native messaging host process is launched by Chrome and listening on its bridge socket, but the Claude Code instance with --chrome flag never connects to that socket. The /chrome slash command does not repair the connection.

Environment

• OS: Ubuntu 24.04.3 LTS (kernel 6.17.0-22-generic)
• Chrome: Google Chrome 146.0.7680.80
• Claude Code: 2.1.128 (versions 2.1.123, 2.1.126, 2.1.128 installed in ~/.local/share/claude/versions/)
• Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn (verified installed and listed as "Claude" in Chrome extensions)
• Launch: claude --dangerously-skip-permissions -c --chrome

Symptom

Calling any mcp__claude-in-chrome__* tool returns:

Browser extension is not connected. Please ensure the Claude browser extension is installed and running (https://claude.ai/chrome), and that you are logged into claude.ai with the same account as Claude Code.

Meanwhile /mcp dialog shows: claude-in-chrome · ✓ connected · 20 tools.

Diagnosis

The MCP server is running, but the bridge to the Chrome extension is broken at the socket layer.

What works

• Chrome extension is installed and matches the manifest (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Native messaging host manifest exists at ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json and points to ~/.claude/chrome/chrome-native-host
• Native host script exists, is executable, and exec's ~/.local/share/claude/versions/2.1.128 --chrome-native-host
• Chrome successfully launches the native host (parent process is /opt/google/chrome/chrome PID 208079)
• Native host process (PID 208352) is alive and listening on its Unix socket:

  u_str LISTEN 0 512 /tmp/claude-mcp-browser-bridge-spinoza/208352.sock 771522 * 0 users:(("2.1.128",pid=208352,fd=11))

• stdio pipes between Chrome (208079) and native host (208352) are alive (Chrome holds FDs 245r, 261w, 2w pointing to inodes 772401, 772402, 774117)
• MCP server inside Claude Code is loaded and exposing 20 tools

What's broken

• The Claude Code instance with --chrome flag (PID 209054, verified via /proc/209054/cmdline) has no socket connection to /tmp/claude-mcp-browser-bridge-spinoza/208352.sock. Verified by iterating its open FDs and cross-referencing with ss -xp for any claude-mcp-browser socket — no match.
• Running /chrome slash command does not establish the connection. It appears to relaunch native host machinery but doesn't trigger the bridge connection on the Claude Code side.

Suspected root cause

Looks like a startup race or missing retry logic. When Claude Code starts with --chrome while Chrome is already running with the extension active and a native host already listening, the bridge-connection step either doesn't run or fails silently with no auto-retry. After init, /chrome does not reattempt the connection.

Side observation

bridge-pointer.json files exist in some project directories (~/.claude/projects/-home-spinoza-github-texwatch/bridge-pointer.json, ~/.claude/projects/-home-spinoza-github-beta-cell-space/bridge-pointer.json) from earlier sessions where the bridge presumably worked, containing {"sessionId": "session_...", "environmentId": "env_...", "source": "repl"}. The current project (~/.claude/projects/-home-spinoza-github-beta-grant-tracker/) has no such file. Unclear whether this is cause or symptom — the existence of the file in other projects suggests there's a persistent record of working bridge connections, and its absence in the current project may indicate the bridge has never successfully linked here.

Steps to reproduce

1. Have Chrome 146 running with Claude extension installed (ID fcoeoabgfenejglbffodgkkbkcdhcgfn)
2. From a project directory: claude --dangerously-skip-permissions -c --chrome
3. Call any mcp__claude-in-chrome__* tool (e.g., tabs_context_mcp with createIfEmpty: true)
4. Observe "Browser extension is not connected" error
5. Run /chrome slash command in the Claude Code session
6. Retry the tool call — same error
7. Verify via ss -lxp | grep claude-mcp-browser that the native host is listening
8. Verify via /proc/<claude-pid>/fd and ss -xp that Claude has no connection to that socket

Workarounds tried (none worked)

• Restarting Chrome
• Re-running /chrome
• Disconnecting and reconnecting the MCP server (which produced the same listed-but-unusable state)
• Verifying the extension is enabled (state in Chrome Preferences is non-disabled)

Diagnostic snapshot

=== claude-in-chrome MCP per /mcp dialog ===
claude-in-chrome · ✓ connected · 20 tools

=== Native host alive, socket listening ===
u_str LISTEN 0 512 /tmp/claude-mcp-browser-bridge-spinoza/208352.sock 771522 * 0 users:(("2.1.128",pid=208352,fd=11))

=== Active `claude --chrome` instance has no connection to bridge socket ===
(no FDs match claude-mcp-browser sockets; verified empty)

=== Process tree ===
chrome(208079)──2.1.128(208352)  [native host launched by Chrome, alive]
claude(209054, --chrome)          [no bridge socket connection]

Impact

claude-in-chrome is unusable in this state for anything that requires the Chrome extension. The MCP server appears connected so users may not realize the bridge is broken until they actually try to call a tool.

Repro environment files (paths, no contents)

• /home/spinoza/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json
• /home/spinoza/.claude/chrome/chrome-native-host
• /tmp/claude-mcp-browser-bridge-spinoza/208352.sock
• ~/.claude/projects/-home-spinoza-github-beta-grant-tracker/ (no bridge-pointer.json)
• ~/.claude/projects/-home-spinoza-github-texwatch/bridge-pointer.json (from earlier working session)

Suggested investigation

1. When Claude Code starts with --chrome, does it scan /tmp/claude-mcp-browser-bridge-spinoza/*.sock and connect? If yes, why didn't it here?
2. Does /chrome slash command attempt the bridge connection from the Claude side, or only ensure the native host is ready?
3. Should there be a retry / reconnect mechanism if the initial connection failed?
4. Should /mcp reflect bridge-down state separately from MCP-protocol-up state, so users don't see "connected" when the underlying transport is broken?