Claude in Chrome: extension never calls connectNative despite correct setup (macOS, v2.1.76, ext v1.0.61)

[hansv]

Description

The Claude in Chrome extension (v1.0.61) never initiates a native messaging connection (chrome.runtime.connectNative) despite being installed, enabled, and correctly configured. The --claude-in-chrome-mcp subprocess starts and registers as a built-in MCP, but returns "Browser extension is not connected" because no native host socket exists.

Environment

• OS: macOS 15.5 (Darwin 24.6.0, Apple Silicon)
• Chrome: 145.0.7632.160
• Claude Code CLI: 2.1.76
• Extension version: 1.0.61
• Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn
• Claude Desktop: Installed but not running

What works

• Extension is installed and enabled (sidebar works, can chat in it)
• Native host binary works: responds to ping/pong correctly via native messaging protocol
• --claude-in-chrome-mcp subprocess works: responds to MCP initialize, returns proper error when no socket found
• End-to-end bridge works when native host is manually started: socket accepts connections, forwards messages via 4-byte length-prefixed protocol
• CLAUDE_CODE_ENABLE_CFC=1 env var correctly enables the built-in MCP (shows "claude-in-chrome · ✓ connected" in built-in MCPs)
• Both native messaging manifests are valid and point to ~/.claude/chrome/chrome-native-host

What doesn't work

• The extension's service worker never calls connectNative — verified by:
  1. Monitoring ps aux for chrome-native-host processes after Chrome restart — none spawned
  2. Wrapping the native host in a logging script — wrapper never executed
  3. Checking /tmp/claude-mcp-browser-bridge-<user>/ — no socket directory created
  4. Multiple Chrome restarts, extension disable/enable cycles, full extension reinstall — no effect

Root cause analysis

Decompiled the extension's service worker (service-worker.ts-C4SRwdsa.js). The connectNative call is in function M(), which is called on:

• Module load: b(),o(),M()
• chrome.runtime.onInstalled
• chrome.runtime.onStartup
• chrome.permissions.onAdded (for nativeMessaging)

M() has guards:

if(I) return true;   // already connected
if(A) return false;  // already attempted, never retries
A = true;

The function checks chrome.permissions.contains({permissions:["nativeMessaging"]}) and typeof chrome.runtime.connectNative === "function" before attempting connection. One of these checks may be failing silently, or b() / o() may be throwing before M() is reached. The service worker console shows no errors.

Steps to reproduce

1. Install Claude Chrome extension (v1.0.61)
2. Verify native messaging manifests exist in ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/
3. Start CLAUDE_CODE_ENABLE_CFC=1 claude --chrome
4. Call any mcp__claude-in-chrome__* tool
5. Get "Browser extension is not connected" error
6. Verify no chrome-native-host process was ever spawned

Troubleshooting attempted

• Full Chrome restart (quit + reopen) — multiple times
• Extension disable/enable toggle
• Extension full uninstall + reinstall from Chrome Web Store
• Cleared extension Local Storage, IndexedDB, Sync Extension Settings
• Set tengu_chrome_auto_enable: true in ~/.claude.json
• Set CLAUDE_CODE_ENABLE_CFC=1 env var
• Renamed/disabled Desktop native messaging manifest (com.anthropic.claude_browser_extension.json)
• Created symlink from os.tmpdir() path to /tmp/ socket directory
• Multiple fresh Claude Code sessions (not resumed)

Notes

• The CLAUDE_CODE_ENABLE_CFC=1 env var is required to even register the MCP — without it, _uT() returns false because s8() (OAuth scope check) fails
• tengu_chrome_auto_enable defaults to false server-side
• The extension tries two host names in order: com.anthropic.claude_browser_extension (Desktop) then com.anthropic.claude_code_browser_extension (Code) — neither gets called

[github-actions]

Found 3 possible duplicate issues:

1. Claude in Chrome: CLI never connects to native host socket (macOS) #34672
2. Chrome integration: Claude Code never connects to native bridge socket (macOS) #32382
3. Claude-in-Chrome: connection fails when Claude Desktop installed despite disabling Desktop's native host (macOS) #34577

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[hansv]

Resolved — the root cause was the tengu_copper_bridge feature flag being set to true in ~/.claude.json. This forces the --claude-in-chrome-mcp subprocess to use a WebSocket bridge client instead of the local Unix socket pool, with no fallback when the bridge fails.

Fix

# 1. Disable the copper_bridge flag
python3 -c "
import json
with open('$HOME/.claude.json', 'r') as f:
    data = json.load(f)
data['cachedGrowthBookFeatures']['tengu_copper_bridge'] = False
with open('$HOME/.claude.json', 'w') as f:
    json.dump(data, f, indent=2)
"

# 2. Start Claude Code with the CFC env var
CLAUDE_CODE_ENABLE_CFC=1 claude --chrome

Both are required:

• tengu_copper_bridge: false — forces local Unix socket mode instead of broken WebSocket bridge
• CLAUDE_CODE_ENABLE_CFC=1 — bypasses the s8() OAuth scope check that prevents the MCP from registering

Credit to @cruzlauroiii on #34672 for identifying the tengu_copper_bridge issue.