Claude in Chrome (Linux): CLI never attempts bridge socket connection — all tools return 'Browser extension is not connected' after exactly 10s, while extension↔native-host channel is verified working

Environment

• OS: Ubuntu 25.10, Wayland (GNOME), kernel 6.17
• Claude Code: 2.1.174 (native installer, ~/.local/share/claude/versions/)
• Session started with the --chrome flag
• Google Chrome stable, extension "Claude in Chrome" v1.0.74 (fcoeoabgfenejglbffodgkkbkcdhcgfn), enabled
• Logged into claude.ai in Chrome with the same account as Claude Code (verified in the extension's options page)

Symptom

Every mcp__claude-in-chrome__* tool call (e.g. tabs_context_mcp) returns the canned message "Browser extension is not connected…" after exactly ~10 seconds, every time.

Key finding

The Chrome side is fully healthy, and the CLI never attempts a connection to the bridge socket:

1. Native messaging manifest is correct (~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json → ~/.claude/chrome/chrome-native-host).
2. The native host spawns and pairs with the extension. Journal on Chrome start:

``
[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: /tmp/claude-mcp-browser-bridge-daniel/385990.sock
[Claude Chrome Native Host] Socket server listening for connections
[Claude Chrome Native Host] Socket permissions set to 0600
[Claude Chrome Native Host] Handling Chrome message type: ping
[Claude Chrome Native Host] Responding to ping
[Claude Chrome Native Host] Handling Chrome message type: get_status
``

1. ss -xlp confirms the socket is LISTENing, owned by the native host process (same uid as the CLI).
2. During tool calls the native host logs zero activity — no connection ever reaches the socket. The 10 s timeout happens entirely inside the CLI process.
3. MCP client log (~/.cache/claude-cli-nodejs/<project>/mcp-logs-claude-in-chrome/*.jsonl) shows the in-process server starting fine, then for every call:

``
{"debug":"Calling MCP tool: tabs_context_mcp", ...}
{"debug":"Tool 'tabs_context_mcp' completed successfully in 10s", ...} ← canned not-connected result
`
The same exactly-10s pattern applies to the automatic set_permission_mode` calls at session start.

Ruled out (each verified, same behavior after)

• Chrome not running (it initially wasn't; started it — no change)
• Version mismatch between ~/.claude/chrome/chrome-native-host wrapper and the CLI (tested matched at 2.1.173↔2.1.173 and 2.1.174↔2.1.174)
• Account mismatch (same account confirmed)
• claude.ai side panel holding the browser session (closed it — no change)
• Full restarts of Chrome and of the CLI session; /mcp reconnect (MCP server reconnects fine — still never dials the socket)
• Running without and with --chrome (identical behavior)

Secondary observation

~/.claude/chrome/chrome-native-host is not regenerated when Claude Code auto-updates: after the 2.1.173 → 2.1.174 update it still pointed at the 2.1.173 binary (which happens to remain on disk, so it still execs). Looks like the updater should refresh this wrapper.

Expected

With --chrome, the in-process Chrome MCP server should discover and connect to /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock.

Happy to provide more logs or run a debug build.

🤖 Generated with Claude Code