Chrome integration: CLI never dials the native-host bridge socket — browser tools always report "Browser extension is not connected" (macOS)

Summary

tabs_context_mcp (and all browser tools) permanently return "Browser extension is
not connected" even though every component of the chain is verified healthy. Root
cause appears to be that the CLI session never dials the bridge socket in
/tmp/claude-mcp-browser-bridge-<user>/ — confirmed by placing a fake listening
socket there and observing zero connection attempts during a browser tool call.

Environment

• Claude Code 2.1.199, macOS 14.2 (Darwin 23.2.0), zsh
• Chrome 149.0.7827.199, Claude in Chrome extension 1.0.79 (ID fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Direct Anthropic plan; CLI and extension signed into the same account (verified:

the CLI's oauthAccount.accountUuid appears in the extension's Local Extension
Settings storage)

• Claude desktop app also installed (relevant — see finding 1)

What works

• Extension installed/enabled in the Default profile, signed in, side panel works
• Native messaging manifest com.anthropic.claude_code_browser_extension.json is

valid; points at ~/.claude/chrome/chrome-native-host → claude --chrome-native-host

• The extension spawns the Claude Code native host, which creates and listens on

/tmp/claude-mcp-browser-bridge-<user>/<pid>.sock — the socket accepts
connections (verified with a manual Python AF_UNIX client)

• ~/.claude.json: claudeInChromeDefaultEnabled: true,

hasCompletedClaudeInChromeOnboarding: true

Findings

1. Desktop app shadows Claude Code. The extension probes native hosts in fixed

order (Desktop first, then Claude Code) and binds to the first that answers a
ping — permanently. With the Claude desktop app installed, its helper
(/Applications/Claude.app/Contents/Helpers/chrome-native-host) always answers
(Chrome spawns it on demand even when the app is closed), so the Claude Code
host is never launched. Workaround applied: renamed
com.anthropic.claude_browser_extension.json → .json.disabled in
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/. After a
Chrome restart the extension correctly spawns the Claude Code host.

1. Even with a healthy Claude Code host, the session never connects. Tried

every restart-order permutation: session before host, host before session, both
fresh, /chrome → "Reconnect extension" repeatedly, killing the
claude daemon process, clearing the com.apple.quarantine xattr Chrome puts
on the bridge dir. In all cases lsof shows the host's socket with zero
clients, and browser tools return "Browser extension is not connected"
immediately.

1. Proof the CLI never dials: killed the real host, created a fake AF_UNIX

listener at /tmp/claude-mcp-browser-bridge-<user>/<live-pid>.sock that logs
every accept, invoked tabs_context_mcp from a claude --chrome session —
the fake host received zero connections.

1. At session startup with --chrome, internal set_permission_mode calls to the

in-process "Claude in Chrome" MCP server each take exactly 10s (timeout?) and
then report success (mcp-logs-claude-in-chrome). Browser tool calls fail
instantly afterwards.

1. /chrome → "Reconnect extension" opens claude.ai/chrome, which redirects to

claude.ai/new without any visible connect/pairing flow. The extension ships a
pairing.html (with a "Claude Code" variant in PairingPrompt), but nothing
ever triggers it.

Expected

Session connects to the extension via the native host bridge; browser tools work.

Actual

"Browser extension is not connected" from all browser tools, always.

🤖 Generated with Claude Code