Named-pipe conflict from many concurrent CLI sessions makes Claude in Chrome permanently report "not connected"

Summary

When many claude.exe processes accumulate on the same Windows machine (in our case ~24, built up over about a week of daily use — most abandoned/orphaned, not real active terminals), every call to mcp__claude-in-chrome__tabs_context_mcp fails with the generic:

Browser extension is not connected. Please ensure the Claude browser extension is installed and running (https://claude.ai/chrome), and that you are logged into claude.ai with the same account as Claude Code. If this is your first time connecting to Chrome, you may need to restart Chrome for the installation to take effect.

This error message points entirely at extension install/login/Chrome-restart causes, none of which was the actual problem, and none of which is fixable by the steps it suggests.

Environment

• Windows 11
• Claude Code CLI 2.1.221 (also reproduced on 2.1.220)
• Claude in Chrome extension 1.0.84, installed from the Chrome Web Store, disable_reasons: [] in Chrome's Secure Preferences (i.e. enabled), has_started_service_worker: true
• Native messaging host correctly registered at HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension, manifest and .bat wrapper both present and pointing at the correct claude.exe

What we ruled out before finding the real cause

We spent ~20 minutes checking (all confirmed fine):

• Extension actually installed in the Chrome profile that's actually running (Local State → last_used)
• Extension enabled, not disabled by policy
• Native messaging host manifest/registry entries correct
• Full Chrome restart (twice) — no change
• Logged into claude.ai with the matching account

Actual root cause

Get-Process -Name claude showed ~24 concurrent claude.exe processes on the machine. Only 7 were tracked as real interactive sessions in %USERPROFILE%\.claude\sessions\*.json; the rest appear to be orphaned/leaked processes (a cluster of ~14 had start timestamps within the same second, suggesting a spawn-storm rather than real terminals). Claude-in-Chrome's native-messaging bridge to the CLI apparently uses a single shared Windows named pipe, so with that many processes contending for it, the extension could never reliably reach any one CLI instance — even though every other piece (extension, manifest, registration) was correctly configured.

Fix that resolved it: killing every claude.exe process except the one behind the active terminal, then one more full Chrome restart. Confirmed working end-to-end afterward (drove a live remote-browser session interactively via the extension with no further issues).

Suggested fixes

1. Cheap: reap/mark-dead orphaned entries in %USERPROFILE%\.claude\sessions\*.json for PIDs that no longer exist, and — if the leaked-process spawn-storm is a real bug independent of this — investigate why ~14 claude.exe processes were spawned within the same second on this machine.
2. Bigger: either scope the native-messaging pipe per-session instead of one shared global pipe (removing the contention entirely), or at minimum detect "many concurrent CLI processes, none can claim the pipe" as a distinct failure mode and surface a more actionable error than the generic install/login message — e.g. "Multiple Claude Code sessions are competing for the browser connection; close other sessions and retry." The current message sent us down a long, unproductive troubleshooting path because it actively suggested the wrong causes.

Happy to provide more diagnostic detail (registry dumps, sessions/*.json contents, process list) if useful.