Chrome MCP: intermittent Native Messaging connection failure when Desktop + CLI coexist (Windows)

Bug Description

The Chrome MCP connection between Claude Code CLI and the Claude-in-Chrome Extension (fcoeoabgfenejglbffodgkkbkcdhcgfn v1.0.47) fails intermittently (~70% failure rate) on Windows when Claude Desktop is also installed. Both applications register separate Native Messaging Hosts for the same Chrome Extension, which may cause race conditions or routing conflicts.

Personal note: I'm a Vibe Coder -- I trust Claude Code 100% for analysis, diagnostics, and code. This entire investigation (root cause analysis, diagnostic scripts, logging wrapper, monitor dashboard, this bug report) was created autonomously by Claude Code (Opus 4.6) with my guidance. I wanted to share this as product feedback too: your tool is genuinely capable of deep system-level debugging on its own. The diagnostics PR, scripts, and this report were all generated in a single session. Impressive product -- this bug is the one thing that keeps tripping me up.

Environment

• OS: Windows 11
• Claude Code CLI: latest (npm, via @anthropic-ai/claude-code)
• Claude Desktop: app-1.1.2512
• Node.js: v22.x
• Chrome Extension: Claude in Chrome v1.0.47 (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Antivirus: Bitdefender (active)

Root Cause Analysis

Native Messaging Host Conflict

Both Claude Desktop and Claude Code register Native Messaging Hosts in the Windows registry under:

HKCU\SOFTWARE\Google\Chrome\NativeMessagingHosts\

| Application | Host Name | Manifest Path | Binary |
| --------------- | ---------------------------------------------- | ------------------------------------------------ | ------------------------ |
| Claude Desktop | com.anthropic.claude_browser_extension | %APPDATA%\Claude\ChromeNativeHost\...json | chrome-native-host.exe |
| Claude Code CLI | com.anthropic.claude_code_browser_extension | %APPDATA%\Claude Code\ChromeNativeHost\...json | chrome-native-host.bat |

Both manifests list the same extension ID in allowed_origins:

chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/

Desktop manifest points to: C:\Users\...\AppData\Local\AnthropicClaude\app-1.1.2512\resources\chrome-native-host.exe
CLI manifest points to: chrome-native-host.bat -> node.exe cli.js --chrome-native-host

Observed Behavior

• Connection succeeds ~30% of the time (verified via debug logs showing 1035ms connect time)
• The Chrome extension itself works perfectly in the sidepanel
• tabs_context_mcp sometimes returns data, sometimes times out with no response
• No clear pattern -- sometimes works after Chrome restart, sometimes not
• Important: Both Desktop and CLI were running simultaneously during BOTH successes and failures, so it's not a simple "both running = broken" situation. It's intermittent.

What Fixed It (Temporarily)

Renaming the Desktop manifest to .disabled made the CLI connection stable (5/5 tests passed immediately). However, correlation is not causation -- this needs more investigation.

Steps to Reproduce

1. Install Claude Desktop (app-1.1.2512) on Windows 11
2. Install Claude Code CLI via npm
3. Install Claude-in-Chrome extension (v1.0.47)
4. Open Chrome with the extension active
5. Start Claude Desktop (leave running in background)
6. Open Claude Code CLI in terminal
7. Attempt to use any Chrome MCP tool (e.g., tabs_context_mcp)
8. Observe: connection fails ~70% of the time across sessions

~7 attempts over multiple sessions were made before this investigation.

Workaround

Renaming the Desktop manifest eliminates one conflict source:

# Disable Desktop manifest (reversible)
Rename-Item "$env:APPDATA\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json" `
  "com.anthropic.claude_browser_extension.json.disabled"

# Re-enable when needed
Rename-Item "$env:APPDATA\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json.disabled" `
  "com.anthropic.claude_browser_extension.json"

This disables Claude Desktop's Chrome browser integration but Desktop itself continues to work.

Diagnostic Tooling Created

Claude Code autonomously created a full diagnostic toolkit during this investigation:

• mcp-monitor.ps1: Real-time dashboard monitoring processes, manifests, registry, and TCP connections
• collect-bug-report.ps1: Automated collector that gathers system info, manifests, registry exports, debug logs, process snapshots, network status, and firewall rules into a ZIP
• chrome-mcp-logger.ps1: Logging wrapper for the native host batch that records startup/exit, Desktop conflict detection, and stderr

All available at: https://github.com/Svenja-dev/ManufacturingInsideAnalyzer/pull/211

Suggested Fix

1. Mutual exclusion: When CLI connects, check for and gracefully handle an active Desktop host
2. Extension-side routing: Detect which host initiated the connection and route messages accordingly
3. Locking mechanism: Prevent simultaneous host registration conflicts for the same extension
4. Documentation: Note the Desktop+CLI coexistence issue in Windows setup docs