claude-code - 💡(How to fix) Fix CLI can't connect to extension while Claude Desktop on same machine can [1 comments, 2 participants]

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?