Claude-in-Chrome: 'extension not connected' persists on 2.1.197 even with live native host; Desktop app can silently claim the extension channel

Summary

Claude-in-Chrome MCP reports "Browser extension is not connected" on every call, even after exhaustively verifying/repairing the pairing preconditions. Root-cause trail suggests two distinct problems: (1) the Claude Desktop app can claim the extension's native-messaging channel, silently breaking Claude Code's browser tools with a misleading error; (2) after fully clearing the desktop channel — with a live claude --chrome-native-host process spawned by the extension — the CLI session still cannot see the browser on v2.1.197.

Environment

• macOS (Darwin 25.5.0)
• Claude Code 2.1.197 (Homebrew cask — current cask version at time of filing; newer builds exist on the native-installer channel)
• Claude in Chrome extension v1.0.80 (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Chrome: multiple profiles; extension installed + enabled in the active profile (verified via profile Preferences: no disable_reasons)
• Extension and Claude Code CLI signed into the same claude.ai account (verified visually in extension settings page and CLI /status)
• Claude Desktop app also installed (Electron 42.5.1 build 1.20186.1)

Timeline / repro

1. Browser tools worked previously (same machine, same account).
2. The Claude Desktop app (re)registered its native-messaging host manifest (com.anthropic.claude_browser_extension.json, file mtime matches the breakage time) and its helper process (/Applications/Claude.app/Contents/Helpers/chrome-native-host chrome-extension://fcoeo.../) held the extension's channel.
3. From that point, every tabs_context_mcp / list_connected_browsers call from Claude Code returned "Browser extension is not connected" — while the extension's own sidebar kept working (desktop channel). The error text (check install / same account / restart Chrome) points users in the wrong direction for this failure mode.
4. Remediation attempted, in order, verifying state at each step:

• Quit Claude Desktop → its helper process survived as an orphan still holding the channel; killed it manually.
• Parked the desktop manifest so only com.anthropic.claude_code_browser_extension.json (→ ~/.claude/chrome/chrome-native-host, wrapper exec'ing the 2.1.197 binary — same version as the running session) remained.
• Extension sign-out/sign-in; extension toggle off/on at chrome://extensions; full Chrome restart.
• After the toggle, the extension did spawn claude --chrome-native-host (process observed running, correct binary, correct version).
• Reconnected the claude-in-chrome MCP server in the CLI session (/mcp → reconnect → "Reconnected").

1. Result: still "Browser extension is not connected" on every call.

Expected

• Claude Code's browser tools connect when the extension is installed, enabled, signed into the same account, and its native host process is running.
• If the Desktop app claims the channel, the error should say so (e.g. "browser is paired with the Claude Desktop app") instead of the generic not-connected text.
• Quitting the Desktop app should not leave an orphaned native-host helper holding the extension channel.

Actual

• Generic "Browser extension is not connected" in all cases, including with a live claude --chrome-native-host process spawned by the extension and no competing desktop channel.

Notes

• A second machine on Claude Code 2.1.207 pairs fine, so this may already be fixed post-2.1.197 — if so, the actionable residue is (a) the misleading error message for the desktop-app-owns-the-channel case and (b) the orphaned desktop helper process after quit.