[Bug] Claude in Chrome: native host connects but CLI pairing layer never completes — list_connected_browsers empty, no chromeExtension record written

Summary

On a fully-correct local setup, claude --chrome browser tools always return Browser extension is not connected. The native messaging host is spawned by Chrome and listens on its socket, but Claude Code's pairing/bridge layer never connects to it and never writes a chromeExtension pairing record to ~/.claude.json. This is the same signature as #20298 (comments by @ohcedar on 2.1.112 and @duongxthanh on 2.1.121), still present on 2.1.201.

Environment

• OS: macOS 26.5.1 (build 25F80)
• Claude Code: 2.1.201 (native installer, ~/.local/share/claude/versions/)
• Chrome: 149.0.7827.201
• Claude in Chrome extension: 1.0.79
• Account: paid; extension and CLI confirmed signed into the same claude.ai account
• Claude Desktop: installed, but force-quit and kept closed during all tests

Symptoms

• mcp__claude-in-chrome__tabs_context_mcp and every other browser tool return Browser extension is not connected.
• list_connected_browsers returns the same "not connected" error — i.e. the account's browser registry is empty from the CLI's perspective.
• The Chrome extension side panel works normally in the browser.

What I verified (local plumbing is fully correct)

1. Native messaging config correct. com.anthropic.claude_code_browser_extension.json → ~/.claude/chrome/chrome-native-host; wrapper → .../versions/2.1.201 --chrome-native-host. (Separately, com.anthropic.claude_browser_extension.json gets rewritten to the Desktop-app path every time Claude Desktop launches — see note below.)
2. Native host spawns and listens. Chrome spawns the CLI native host as a child process; it creates and listens on /tmp/claude-mcp-browser-bridge-$USER/<pid>.sock.
3. But nothing on the CLI side ever connects to that socket. lsof shows exactly one holder — the native host itself, listening. The claude --chrome session process has zero bridge fds.
4. No pairing record written. After /mcp reconnect (×2), /chrome reconnect, and full session restarts, ~/.claude.json still only contains cachedChromeExtensionInstalled, claudeInChromeDefaultEnabled, hasCompletedClaudeInChromeOnboarding — never a chromeExtension pairing record.
5. Both code paths fail identically. Registering the MCP server explicitly (command: <claude>, args: ["--claude-in-chrome-mcp"], per the workaround in #14894) produces a dedicated process that reports MCP-connected, but its browser tools and list_connected_browsers fail exactly the same way.

Steps already tried (none resolve it)

• Repointed the reverted native-host config back to the CLI path (twice)
• Force-quit Claude Desktop and kept it closed
• Killed stale/orphaned native hosts so a fresh one spawns bound to the current live session
• /mcp → Reconnect (×2), /chrome → Reconnect
• Full claude session restarts (×2)
• Confirmed extension + CLI on the same claude.ai account
• Explicit --claude-in-chrome-mcp MCP server registration (#14894 workaround)

Diagnosis

The extension → native-host launch path works and the socket is live, but Claude Code's pairing/bridge layer never completes — it neither connects to the native-host socket nor registers the browser with the account. This matches the unresolved reports in #20298 and appears independent of Claude Code version (seen on 2.1.112, 2.1.121, and 2.1.201).

Note on the config-revert side issue

Launching the Claude Desktop app rewrites com.anthropic.claude_browser_extension.json's path back to /Applications/Claude.app/Contents/Helpers/chrome-native-host, overwriting a CLI fix. That's a separate, lower-severity annoyance; fixing it does not resolve the pairing-layer failure above.