Chrome extension reconnect fails intermittently even after fixing native-messaging host conflict (macOS)

Additional confirmed detail on the trigger: this was working fine as of yesterday. It broke specifically after updating the Claude Desktop app today — the update re-registered/overwrote com.anthropic.claude_browser_extension.json (confirmed via file timestamp matching the update time), which is what introduced the native-messaging host conflict described above. So the regression path is:

1. Claude Code + Claude Desktop coexist fine (Code's native host manifest was in place, presumably not being overridden).
2. Claude Desktop app auto-updates or is manually updated.
3. The update re-writes com.anthropic.claude_browser_extension.json pointing back at Desktop's own native host binary, re-introducing the extension-ID conflict with Code's manifest.
4. Chrome extension reconnect to Claude Code breaks from that point on, even though it worked immediately before the Desktop update.

Applying the manifest workaround from #20887 gets the native host spawning correctly again, but the reconnect handshake itself still doesn't complete (see root cause #2 above) — so a Desktop update is a reliable way to reproduce this regression from a previously-working state.

Follow-up: found a working workaround for the stuck-session symptom described above (root cause #2).

We confirmed the native-messaging bridge itself was genuinely healthy — a second Claude Code session, opened in a different project directory around the same time, connected successfully through the exact same native-host process and socket (verified by matching PIDs/socket names, plus a live tabs_context_mcp call that returned real tab data). Meanwhile the original session (same machine, same bridge, different project directory) kept failing /chrome reconnect attempts indefinitely, with no config or settings differences between the two projects.

Workaround: duplicated the stuck project's directory to a new path and opened a fresh Claude Code session there. /chrome connected immediately in the new session, no other changes needed.

This points to per-session/per-pairing state getting stuck (possibly an exclusive-pairing race when multiple sessions attempt /chrome around the same time, where the "losing" session's connection attempt is silently dropped and never retries cleanly) rather than anything wrong with the bridge, the extension, or the project's config. A stuck session doesn't seem to recover on its own even after multiple manual /chrome reconnect attempts, a full Chrome restart, and a full Claude Code CLI restart in the same directory — only starting fresh in a new directory (and therefore a new session) resolved it.

Comment for anthropics/claude-code#90385

Same symptom set on another macOS machine; adding diagnostics that narrow the failure to the CLI-side pairing step. Happy to provide more logs.

Environment

• macOS 26.6.2 (Apple Silicon)
• Chrome 154.0.8037.93, profile "Default" (extension installed and signed in, same account as CLI)
• Claude in Chrome extension ID fcoeoabgfenejglbffodgkkbkcdhcgfn
• Claude Code 2.1.287 (native install, ~/.local/bin/claude → Mach-O arm64) — also reproduced identically after downgrading to 2.1.250
• Claude Desktop also installed (manifest conflict found and fixed, see below)

Symptom

/chrome → "Reconnect extension": a tab opens on the reconnect page and closes immediately. Status stays Disabled / Extension: Installed. /mcp never lists a claude-in-chrome server. Browser MCP tools never become available.

What was verified step by step

1. Native-host manifest conflict (root cause #1 of this issue) was present and fixed.

Initially only the Desktop app's manifest existed (com.anthropic.claude_browser_extension.json → /Applications/Claude.app/Contents/Helpers/chrome-native-host); ~/.claude/chrome/ was empty (Claude Code had never installed its host — same as #14894). I created ~/.claude/chrome/chrome-native-host (wrapper exec'ing claude --chrome-native-host) plus com.anthropic.claude_code_browser_extension.json, and also pointed the Desktop manifest's path at the Code host per the #20887 workaround. After a full Chrome restart, logging in the wrapper confirms Chrome now spawns the correct (Claude Code) native host.

1. Extension ↔ native host channel works.

Wrapper log on every Chrome launch / reconnect attempt:
``
[wrapper] invoked ... args=chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/
[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: /tmp/claude-mcp-browser-bridge-n0r41n/<pid>.sock
[Claude Chrome Native Host] Socket server listening for connections
[Claude Chrome Native Host] Handling Chrome message type: ping
[Claude Chrome Native Host] Responding to ping
[Claude Chrome Native Host] Handling Chrome message type: get_status
[Claude Chrome Native Host] Removed empty socket directory
`
So the extension connects, health-checks (ping/get_status) — but no pairing/connect flow ever follows; shortly after, the extension drops the connection (host logs Chrome disconnected (EOF received) in ~/Library/Logs/Claude/chrome-native-host.log`).

1. The CLI never touches the bridge socket.

While a host instance stayed alive with its socket open (lsof showed only the host itself on /tmp/claude-mcp-browser-bridge-n0r41n/<pid>.sock), repeated /chrome → Reconnect attempts from the running CLI session produced zero new native-host invocations and zero client connections on the socket. The CLI reports "Disabled" without ever attempting the local transport, and /mcp shows no claude-in-chrome server at all.

1. Ruled out:

• Fresh project directory (per the workaround in this thread): same failure in a brand-new dir.
• DISABLE_GROWTHBOOK=1 (to force feature-flag defaults / avoid the tengu_copper_bridge cloud-bridge path — the cached flag is true and gets re-fetched if edited): no change.
• Downgrade to 2.1.250: identical behavior.
• Extension service-worker console during reconnect: no errors logged at all.
• Same claude.ai account on extension and CLI; extension side panel works standalone.

Reading

Everything local (manifests, native host, socket, extension health-check) is demonstrably working; the failure is in the CLI-side pairing step, which neither completes via the cloud bridge nor falls back to the live local socket — matching root cause #2 described in this issue.