Claude in Chrome extension: hard-coded native-host priority makes CLI unreachable when Claude Desktop is also installed

Summary

On a machine with both Claude Desktop and the Claude Code CLI installed, the Claude in Chrome extension always bonds to the Desktop native host, so CLI mcp__claude-in-chrome__* tools return "No Chrome extension connected". There is no user-facing way to override this.

Environment

• macOS (Darwin 25.4.0)
• Claude Code CLI 2.1.117
• Claude Desktop 1.3561.0
• Claude in Chrome extension 1.0.68 (extension id fcoeoabgfenejglbffodgkkbkcdhcgfn)

Repro

1. Install Claude Desktop. It writes ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json.
2. Install Claude Code CLI. It writes com.anthropic.claude_code_browser_extension.json alongside.
3. Start Chrome, let the extension bond.
4. From the CLI, call any mcp__claude-in-chrome__* tool.

Result: "No Chrome extension connected". Expected: tool succeeds regardless of whether Desktop is also installed.

Root cause (from bundled code)

The extension's service worker hard-codes priority:

const s = [
  {name: "com.anthropic.claude_browser_extension",      label: "Desktop"},
  {name: "com.anthropic.claude_code_browser_extension", label: "Claude Code"}
];
for (const a of s) {
  const t = chrome.runtime.connectNative(a.name);
  // send ping; on pong, bond and stop probing
}

(Lifted from assets/service-worker.ts-Cw4emUEP.js in extension 1.0.68. Desktop is tried first; if it responds, the CLI host is never tried.)

Secondary aggravating factor: Claude Desktop's hnr() in app.asar rewrites com.anthropic.claude_browser_extension.json on every launch, unconditionally (no check for existing file or user preference). So manual workarounds that rename/disable the manifest get clobbered.

What I'd like fixed (preference order)

1. User setting in the extension options page to pick the preferred host — "Desktop" / "Claude Code" / "Auto".
2. Invert the default priority when the CLI host is detectable on disk. The CLI install is more recent and opt-in; Desktop is a baseline install for many users.
3. Document a supported workaround. At minimum, publish whatever Anthropic recommends — don't leave users to reverse-engineer the service worker.

Local workaround (in case others hit this)

I built a small local switch: a dispatcher at the desktop manifest's path and the manifest locked with chflags uchg so Claude Desktop's launch-time rewrite silently fails (the install code swallows the EPERM into a M.debug(...) log — confirmed by observing manifest mtime across a desktop-app restart). The dispatcher reads a mode file to decide whether to exit (fall through to CLI host) or exec the real desktop binary. claude-chrome cli|desktop flips the mode.

Happy to share the scripts if useful — local-only, no reason to publish them in a repo unless the pattern turns out to be the long-term answer.