Claude in Chrome extension always binds to Desktop's native-messaging host, never the CLI's, even with Desktop fully quit

Description

claude-in-chrome MCP tools (tabs_context_mcp, list_connected_browsers) always report "Browser extension is not connected" / return an empty browser list, even after full extension login, permission grants, and repeated Chrome restarts. Root cause traced to: the Claude extension only ever spawns Claude Desktop's native-messaging host, never the Claude Code CLI's, regardless of whether Desktop is installed, running, or even open.

Environment

• macOS (Darwin 25.6.0)
• Claude Code CLI: 2.1.235 (also reproduced on 2.1.234)
• Claude extension (Chrome Web Store "Claude"): v1.0.85
• Chrome: 151.0.7922.138
• Claude Desktop app also installed: v1.30096.5

Steps to reproduce

1. Have both Claude Desktop and Claude Code CLI installed on the same Mac.
2. Install/enable the Claude in Chrome extension, log in with the same account used by the CLI.
3. From an interactive claude session, call mcp__claude-in-chrome__tabs_context_mcp.

Expected

Extension connects to the CLI's native-messaging host (com.anthropic.claude_code_browser_extension, registered at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json, pointing at ~/.claude/chrome/chrome-native-host), and tabs_context_mcp succeeds.

Actual

• tabs_context_mcp always returns: "Browser extension is not connected. Please ensure the Claude browser extension is installed and running..."
• list_connected_browsers always returns [].
• Process monitoring (ps aux | grep chrome-native-host) shows Chrome only ever spawns /Applications/Claude.app/Contents/Helpers/chrome-native-host (Desktop's host, registered under com.anthropic.claude_browser_extension). It never spawns the CLI's host script.

What we already ruled out

• Extension not logged in — confirmed logged in; extension's LevelDB storage (Local Extension Settings/<ext-id>/) contains valid, repeatedly-refreshed accessToken/refreshToken pairs for the correct account.
• Extension disabled / missing permissions — confirmed enabled, "On all sites" access, nativeMessaging permission granted (verified via chrome://extensions detail page and Secure Preferences JSON).
• Stale Chrome process / needs restart — fully quit and relaunched Chrome (osascript ... quit + reopen); native host still resolved to Desktop's binary, and tabs_context_mcp still failed.
• CLI OAuth token missing scope — ran /login in the CLI session to force a fresh, properly-scoped token (per a workaround reported in #65682 for a superficially identical error with a different root cause). Login succeeded; tabs_context_mcp still failed afterward.
• Claude Desktop actively running / holding the socket — fully quit Claude Desktop app (osascript -e 'tell application "Claude" to quit'), manually killed the leftover chrome-native-host process it had spawned, deleted the stale bridge socket in /tmp/claude-mcp-browser-bridge-$USER/, and did a full Chrome restart. Chrome still spawned Desktop's native-host binary again on the very next native-messaging connection, even with Desktop fully closed — meaning the extension is hardcoded/prioritized to Desktop's manifest (com.anthropic.claude_browser_extension) rather than picking the CLI's (com.anthropic.claude_code_browser_extension) based on which is actually running.
• Wrong Chrome profile — extension is installed and independently authenticated in two profiles on this machine; reproduced in the profile where the extension's own login was actively confirmed valid (see above).

Native messaging host manifests present (for reference)

~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
  -> path: /Applications/Claude.app/Contents/Helpers/chrome-native-host   (Desktop's host — the one that always gets used)

~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json
  -> path: ~/.claude/chrome/chrome-native-host   (CLI's host — confirmed present, executable, and functional when run manually; never invoked by Chrome)

Running the CLI's native host manually confirms it works fine standalone:

$ ~/.claude/chrome/chrome-native-host
[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock
[Claude Chrome Native Host] Socket server listening for connections
[Claude Chrome Native Host] Socket permissions set to 0600

So the CLI-side host is not the problem — the extension simply never routes to it while Desktop's manifest also exists on the machine, whether or not Desktop is running.

Suggested fix direction

Either:

• Have the extension select the native-messaging host dynamically based on which client (Desktop vs CLI) initiated the current session/tool call, rather than a fixed priority/first-match on com.anthropic.claude_browser_extension, or
• Support both hosts concurrently (fan-out / multiplex), or
• At minimum, surface a clearer error when this specific collision is detected, instead of the generic "Browser extension is not connected" message (which is also reused for at least one unrelated bridge-side 403/scope error per #65682, making this class of failure hard to self-diagnose).

Related closed/stale issues describing the same underlying collision without a resolved fix: #65682, #46869, #20546.