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

Environment

• OS: macOS 26.6.2 (Build 25G83)
• Chrome: 152.0.7977.65
• Claude Code: 2.1.250
• Extension: Claude (Claude in Chrome), version 1.0.85, ID fcoeoabgfenejglbffodgkkbkcdhcgfn
• Both Claude Desktop app and Claude Code CLI are installed.

Summary

/chrome → "Reconnect extension" fails to establish the browser bridge. The reconnect flow opens a window/tab, which closes (or hangs on a blank page) before pairing completes. mcp__claude-in-chrome__* tools never become available.

Root cause #1 (confirmed, matches #20887 / #21582 / #20341)

Both Claude Desktop and Claude Code register native messaging hosts under different host names but the same allowed extension ID:

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

With both installed, Chrome/the extension consistently routed native-messaging connections to the Desktop app's host instead of Code's — confirmed by observing /Applications/Claude.app/Contents/Helpers/chrome-native-host spawn as a child of Chrome every time /chrome reconnect was attempted, even after fully quitting the Desktop app (the extension itself re-triggers the connection, not a lingering process).

Workaround applied (per #20887): edited com.anthropic.claude_browser_extension.json's path to point at Code's native host binary instead, then fully restarted Chrome. After this, ~/.claude/chrome/chrome-native-host (invoked as claude --chrome-native-host) correctly spawns and opens its bridge socket at /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock.

Root cause #2 (still unresolved — new)

Even with the correct native host now spawning and holding a live bridge socket, the CLI still reports the browser as not connected, and behavior of the reconnect popup is inconsistent across attempts:

• Sometimes the popup opens and closes almost immediately (before any native host process spawns at all).
• Sometimes it hangs indefinitely on a blank page at clau.de/chrome/reconnect.
• Sometimes the correct native host process spawns and a bridge socket is created, but mcp__claude-in-chrome__* tools still never become available in the CLI session.

Ruled out as causes: TLS interception/AV/proxy (checked cert issuers for bridge.claudeusercontent.com and claude.ai, both clean; no proxy configured; no AV/firewall software installed), Gatekeeper/quarantine (native host binary has no com.apple.quarantine attribute and is validly Developer-ID signed), ad-blocker/privacy extensions (disabled, no change), popup blockers (disabled, no change), stale processes/sockets (killed and retried with clean state, no change).

This suggests a second, separate bug in the reconnect handshake itself (possibly a race between the popup page and the native-messaging connectNative call, or the extension not signaling successful pairing back to an already-running CLI session).

Steps to reproduce

1. Have both Claude Desktop and Claude Code CLI installed on macOS with the Claude Chrome extension.
2. Run /chrome in Claude Code CLI, click "Reconnect extension".
3. Observe the popup window opening and closing/hanging without completing pairing.
4. Apply the manifest workaround from #20887 and fully restart Chrome.
5. Retry /chrome reconnect — native host now spawns correctly, but connection still does not register as established in the CLI session.