CLI can't connect to extension while Claude Desktop on same machine can

Summary

claude --chrome in a terminal session fails to connect to the Claude browser
extension. Every mcp__claude-in-chrome__* tool call returns:

Browser extension is not connected. Please ensure the Claude browser extension is installed and running…

The same extension, same Chrome, same macOS user works fine when driven from
Claude Desktop. So the extension, native messaging host, and manifest are all
healthy — the CLI is the only thing that can't pair.

Environment

• macOS 15 (Darwin 25.4.0), Apple Silicon
• Claude Code CLI: 2.1.114 (at /Users/<user>/.local/share/claude/versions/2.1.114)
• Google Chrome: 147.0.7727.57, single Default profile
• Claude extension: id fcoeoabgfenejglbffodgkkbkcdhcgfn, v1.0.68
• /chrome menu reports: Status Enabled, Extension Installed

Reproduction

1. Launch Chrome. Extension auto-connects to its native host on startup.
2. In a fresh terminal: claude --chrome.
3. In the session, invoke any mcp__claude-in-chrome__* tool (e.g. tabs_context_mcp).
4. Tool returns "Browser extension is not connected".
5. In parallel, launch Claude Desktop and drive the same extension from there — it works.

Also reproduced with claude --dangerously-skip-permissions --chrome and with claude --chrome alone.

What I verified on the machine

• Native messaging manifest is registered and points at a valid wrapper:

~/Library/Application
Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json
→ path: /Users//.claude/chrome/chrome-native-host
→ allowed_origins: chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/

• Wrapper is executable and exec's `/Users/<user>/.local/share/claude/versions/2.1.114

--chrome-native-host`.

• The native host process is running as a child of Chrome

(ps shows … 2.1.114 --chrome-native-host, PPID = Chrome PID).

• It has a listening Unix socket:

/tmp/claude-mcp-browser-bridge-<user>/<native-host-pid>.sock (mode srw-------).

• lsof -p <cli-pid> on the CLI process shows no fd connected to that socket dir

— the CLI never opens the bridge.

• Chrome extension's service-worker DevTools console is empty during the failing

MCP calls — the extension receives nothing from the CLI.

• Timing: native host was spawned ~1s after Chrome started, before the CLI

launched. A stale "Claude Desktop" manifest com.anthropic.claude_browser_extension.json.disabled
exists alongside, but its host name differs, so it shouldn't be in the way.

• Restarting Chrome, restarting the CLI, and "Reconnect extension" from the

/chrome menu did not change behavior.

Expected

CLI session pairs with the running native host and tabs_context_mcp returns
tab information, same as when Claude Desktop drives the extension.

Actual

CLI never connects to the bridge socket; extension service worker sees no
messages; MCP tools report "Browser extension is not connected".

Notes / hypotheses

Looks like a CLI-side pairing/discovery bug: the native host and socket are
up, but the CLI doesn't register with the extension or connect to the existing
socket. Could be related to the host being spawned on Chrome startup
(before any CLI exists) and the CLI not adopting it afterwards.

Happy to collect additional logs — is there a DEBUG=… or verbose flag that
would surface the CLI-side handshake attempt?