Claude in Chrome: CLI never connects when Claude Desktop is installed — extension binds only to Desktop's native host

Summary

All mcp__claude-in-chrome__* tools return "Browser extension is not connected" even though the extension is installed, enabled, signed in (sidebar works fine), and on the same account as Claude Code. Root cause appears to be that when the Claude Desktop app is also installed, the Chrome extension only ever spawns the Desktop app's native messaging host — and the Claude Code CLI never attaches to the resulting bridge socket.

Environment

• Claude Code: 2.1.165 (also reproduced on 2.1.163)
• macOS: Darwin 25.5.0 (Apple Silicon)
• Chrome: 148.0.7778.216
• Claude in Chrome extension: 1.0.74 (fcoeoabgfenejglbffodgkkbkcdhcgfn), installed + enabled in the active Default profile
• Claude Desktop app: 1.10628.0 installed (not running during repro)
• Extension signed in; same account as Claude Code; hasCompletedClaudeInChromeOnboarding: true, claudeInChromeDefaultEnabled: true

Symptom

Every call to tabs_context_mcp / list_connected_browsers immediately returns "Browser extension is not connected…" regardless of state.

Diagnostic findings

Two native messaging manifests exist in ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/:

• com.anthropic.claude_browser_extension.json → /Applications/Claude.app/Contents/Helpers/chrome-native-host (Desktop)
• com.anthropic.claude_code_browser_extension.json → ~/.claude/chrome/chrome-native-host (Claude Code wrapper → claude --chrome-native-host)

Both allow extension origin fcoeoabgfenejglbffodgkkbkcdhcgfn.

1. The extension always spawns the Desktop app's host, never Claude Code's. On Chrome startup or extension wake (clicking the icon), the only native host process is /Applications/Claude.app/Contents/Helpers/chrome-native-host, which creates /tmp/claude-mcp-browser-bridge-$USER/<pid>.sock. ~/.claude/chrome/chrome-native-host is never launched. (Desktop app itself not running.)
2. The CLI never attaches to the bridge socket. lsof on the socket shows only the host process itself — no client connection appears when the MCP tools are called. The failure is instant, suggesting the CLI isn't attempting/locating the socket.
3. Claude Code's native host works when run manually: ~/.claude/chrome/chrome-native-host initializes, logs Creating socket listener: /tmp/claude-mcp-browser-bridge-$USER/<pid>.sock, sets 0600 perms, and the socket accepts connections (verified with a raw unix-socket connect).
4. Experiment: patched the Desktop manifest's path to point at the Claude Code wrapper. The extension then spawned claude 2.1.165 --chrome-native-host and its socket was live + accepting connections — but the CLI still reported "not connected", including from a fresh session started after the socket existed. (Manifest restored afterward.)
5. Stale socket cleanup bug (secondary): killing the native host (SIGTERM) leaves the dead <pid>.sock file behind in /tmp/claude-mcp-browser-bridge-$USER/.

Ruled out

• Account mismatch (extension + CLI same account; sidebar greets the user and responds)
• Chrome not restarted (full quit verified by process start time, relaunched fresh)
• Stale CLI session state (multiple full session restarts, including with healthy socket pre-existing)
• /chrome reconnect flow (ran it; no change)
• Extension disabled / wrong profile (enabled, active Default profile)
• Stale sockets (manually cleaned; fresh host + fresh socket made no difference)

Expected

• CLI connects to the extension when the Desktop app is also installed; or
• The error message distinguishes the actual failure (no socket found / handshake failed / host version mismatch / account mismatch) instead of the generic "extension is not connected" for all cases.