Claude-in-Chrome: WebSocket bridge fails on Windows, no way to permanently use local named pipe

Description

Claude-in-Chrome browser automation fails on Windows 10 when the tengu_copper_bridge feature flag routes the MCP server through wss://bridge.claudeusercontent.com instead of using the local named pipe (\.\pipe\claude-mcp-browser-bridge-{username}).

The cloud WebSocket bridge connects but fails silently — the MCP server repeatedly connects/disconnects in a loop and never establishes a working session. The local named pipe works perfectly.

Environment

• OS: Windows 10 Pro 10.0.19045
• Claude Code: 2.1.71 (npm)
• Node.js: v22.14.0
• Auth: OAuth (claude.ai), Max subscription
• Chrome Extension: v1.0.59

Steps to Reproduce

1. Install Claude Code on Windows 10
2. Install Chrome extension, complete /chrome onboarding
3. Run claude — /chrome shows Status: Enabled, Extension: Installed
4. Call any mcp__claude-in-chrome__* tool → returns "No Chrome extension connected"

Root Cause

The tengu_copper_bridge feature flag is set to true server-side. This causes Cbz() to return the bridge URL, which makes gi1() choose the BridgeClient (WebSocket) path instead of the local socket client path.

When running the MCP server manually with NODE_DEBUG=net, we can see it connecting to bridge.claudeusercontent.com:443 and then cycling through connect/destroy/reconnect loops without ever establishing a working session:

NET: connect: find host bridge.claudeusercontent.com
NET: connect/multiple: attempting to connect to 160.79.104.10:443
NET: connect/multiple: connection attempt completed with status 0
NET: afterConnect
NET: _final: not ended, call shutdown()
NET: destroy
NET: close
(repeats indefinitely)

Meanwhile, the local named pipe is alive and connectable — net.connect('//./pipe/claude-mcp-browser-bridge-{username}') succeeds instantly.

Workaround

Setting cachedGrowthBookFeatures.tengu_copper_bridge = false in ~/.claude.json forces the local pipe path and everything works. However, Claude Code re-fetches feature flags from the server on every startup and resets it to true, requiring a wrapper script to patch the config before every launch.

Feature Request

Please provide one of the following:

1. An environment variable (e.g., CLAUDE_CODE_DISABLE_BRIDGE=1) to permanently opt out of the WebSocket bridge and use the local named pipe instead
2. A config setting (e.g., claudeInChromeBridgeMode: "local") that takes precedence over the server-side feature flag
3. Fix the WebSocket bridge on Windows so it doesn't silently fail

Diagnostic Info

The architecture works as follows:

Chrome Extension → Native Messaging (stdio) → Native Host → Named Pipe → MCP Server → Claude Code

• Native host creates pipe: ✅ works
• Pipe is connectable: ✅ works
• MCP server via local pipe: ✅ works (when bridge is disabled)
• MCP server via cloud bridge: ❌ fails (connect/disconnect loop)

The CLAUDE_CODE_ENABLE_CFC=1 env var and claudeInChromeDefaultEnabled: true config are both set correctly. The issue is specifically the bridge transport, not the feature enablement.