Claude in Chrome never connects when Claude Desktop is installed (extension keeps the first native host that pongs; Desktop helper pongs while the app is closed)

Environment: macOS 15/25.x (Darwin 25.6), Chrome stable, Claude Code
2.1.237/2.1.238, Claude Desktop installed, Chrome extension Claude
1.0.85 (fcoeoabgfenejglbffodgkkbkcdhcgfn), signed into claude.ai in the
same profile.

Symptom: every mcp__claude-in-chrome__* call returns "Browser
extension is not connected…" regardless of Chrome restarts, in fresh
--chrome sessions included.

Root cause (verified by reading the extension's service worker and by
direct native-messaging pings): the extension probes native hosts in
order [com.anthropic.claude_browser_extension (Desktop),
com.anthropic.claude_code_browser_extension (Claude Code)] and breaks
on the first host that answers {"type":"ping"} with a pong. The Desktop
helper at /Applications/Claude.app/Contents/Helpers/chrome-native-host
answers pong even when Claude.app is not running (verified with a
framed stdio ping while the app was quit). Result: on any machine with
Claude Desktop installed, the Claude Code host is never selected, its
bridge socket in /tmp/claude-mcp-browser-bridge-$USER/ never exists,
and Claude Code's CLI client (which scans that directory) has nothing to
connect to — the integration is structurally dead, not misconfigured.

Local proof: removing the extension ID from the Desktop host's
manifest allowed_origins and restarting Chrome makes the extension
select the Claude Code host (observed versions/<v> --chrome-native-host
spawn and create <pid>.sock). That workaround breaks Desktop↔Chrome and
is silently reverted by every Claude.app update, so it is not a fix.

Suggested fixes (any of):

1. Extension connects to BOTH hosts concurrently instead of first-pong-wins.
2. Desktop helper declines the ping (or exits) when Claude Desktop is not

running, letting the loop fall through to Claude Code.

1. A user-visible host preference in the extension settings.
2. Claude Code CLI speaks the Desktop host's bridge protocol so one host

serves both clients.

Secondary issue: when the selected host dies with the MV3 service
worker, the extension does not reconnect until the next Chrome restart —
scheduleReconnect on the CLI side then retries forever against an empty
directory. A lazy reconnect on worker wake would make the bridge
self-healing.

---
🤖 Generated with Claude Code

https://claude.ai/code/session_01VrtqeBTdx1dfQv8XkdpYbz