Chrome extension fails to connect: native-host socket exists but Code session never dials it (workaround from #35675 insufficient)

Summary

The workaround posted in #35675 — wrap claude --chrome to flip cachedGrowthBookFeatures.tengu_copper_bridge to false in ~/.claude.json before launch — is not sufficient on Claude Code 2.1.119 / Claude in Chrome (Beta) 1.0.69 / macOS 14.x. The Chrome extension can spawn the Code-side native-host helper and the helper creates a bridge socket, but the user's interactive claude --chrome session never connects to that socket. mcp__claude-in-chrome__tabs_context_mcp consistently returns Browser extension is not connected.

Environment

• Claude Code: 2.1.119 (installed at ~/.local/share/claude/versions/2.1.119, symlinked from ~/.local/bin/claude)
• Claude in Chrome (Beta) extension: 1.0.69 (extension ID fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Google Chrome: current stable on macOS Darwin 25.3.0 (Apple Silicon)
• Native-messaging manifest at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json is correct (path ~/.claude/chrome/chrome-native-host, allowed_origins matches the extension ID)
• Conflicting Claude Desktop manifest (com.anthropic.claude_browser_extension.json) renamed to .disabled so only Code's manifest is reachable

Workaround applied

The wrapper from #35675 is in place at ~/.local/bin/claude-chrome:

#!/bin/sh
python3 -c "
import json, os
p = os.path.expanduser('~/.claude.json')
with open(p, 'r') as f:
    data = json.load(f)
data.setdefault('cachedGrowthBookFeatures', {})['tengu_copper_bridge'] = False
with open(p, 'w') as f:
    json.dump(data, f, indent=4)
"
exec claude --chrome "\$@"

Launched via claude-chrome --continue.

Observed state

After session has been running for ~10 minutes:

• Process tree shows my interactive session (claude --chrome --continue) AND a Chrome-spawned native-host (~/.local/share/claude/versions/2.1.119 --chrome-native-host).
• Native-host has the bridge socket open: /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock (verified via lsof -p <native-host-pid> showing unix ... /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock).
• Interactive session has zero unix sockets open (lsof -p <session-pid> | grep sock returns nothing).
• The tengu_copper_bridge flag value at the time of inspection: True. So GrowthBook re-flipped it after the wrapper's write (consistent with the issue thread's note about the ~5s reset).

Hypothesis

Either:

1. Claude Code re-evaluates tengu_copper_bridge at runtime (not just at startup), and switches away from the local socket bridge once GrowthBook flips it back to true; OR
2. GrowthBook's network response lands before Code finishes its config-read on startup, so Code never saw false to begin with.

The #35675 thread's wrapper assumes startup-only evaluation. That assumption may have changed in a recent Claude Code version.

Repro

1. Install Claude in Chrome extension, sign in to claude.ai.
2. Install the wrapper above.
3. Launch with claude-chrome (or claude-chrome --continue).
4. From within the session, invoke any mcp__claude-in-chrome__* tool (e.g. tabs_context_mcp).

Expected: tool returns tab list / context.
Actual: tool returns Browser extension is not connected.

Diagnostic checks worth running

• Does Claude Code re-read cachedGrowthBookFeatures.tengu_copper_bridge after startup?
• Should the wrapper also block GrowthBook fetches (e.g. via /etc/hosts) for the local-bridge mode to stick?
• Is there a documented internal env var that pins Code to the local Unix-socket bridge regardless of GrowthBook?

Notes

• Falling back to Playwright against a cloud dev URL works fine for our current testing needs, so this is not blocking — quality of life regression vs. earlier versions.
• I'm happy to capture additional logs (--debug=chrome / equivalent) if a maintainer can point at the right flag.

References: #35675