Claude in Chrome: extension not connected on Linux despite working native host (Profile 4 → Default migration)

Environment

• Claude Code: v2.1.74
• OS: Ubuntu 22.04 (Linux 6.8.0-94-generic, x86_64)
• Chrome: 145.0.7632.116
• Extension: Claude v1.0.59 (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Node: v18.20.8
• Plan: Claude Max

Problem

All mcp__claude-in-chrome__* tools return "Browser extension is not connected" despite the entire local chain being verified as working:

1. Extension installed and enabled with nativeMessaging permission
2. Logged into claude.ai in Chrome (same account as Claude Code CLI)
3. Native messaging host config present and correct in ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json
4. Native host process running (--chrome-native-host, spawned correctly)
5. Unix socket created at /tmp/claude-mcp-browser-bridge-{user}/{pid}.sock
6. Socket is connectable (verified with Python socket.connect())
7. claude --chrome flag used, status bar shows "Claude in Chrome enabled"
8. /login re-authentication completed (Chrome set as default browser for OAuth flow)

Root cause identified: Chrome profile mismatch

The extension was originally installed in Profile 4 (non-default). Claude Code detected it there and connected successfully on Mar 2, 2026 (debug log confirms: Extension fcoeoabgfenejglbffodgkkbkcdhcgfn found in chrome Profile 4, connected in 63ms).

After Mar 2, connection stopped working. Troubleshooting steps taken:

1. Installed extension in Default profile (confirmed: ~/.config/google-chrome/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn/1.0.59_0/)
2. Logged into claude.ai in Default profile (Google auth with correct account)
3. Set Chrome as default browser (xdg-settings set default-web-browser google-chrome.desktop)
4. Re-authenticated via /login (OAuth now opens in Chrome, not Firefox)
5. Killed stale native host processes
6. Full Chrome restart
7. Fresh claude --chrome session

None of these resolved the issue. The native host runs, socket is created, but the extension never initiates the connection to the native host.

Debug evidence

Working session (Mar 2):

[Claude in Chrome] Found chrome profiles: Default, Profile 2, Profile 3, Profile 4, Profile 5, Profile 7, Profile 8
[Claude in Chrome] Extension fcoeoabgfenejglbffodgkkbkcdhcgfn found in chrome Profile 4
Bridge URL: wss://bridge.claudeusercontent.com
MCP server "claude-in-chrome": In-process Chrome MCP server started
MCP server "claude-in-chrome": Successfully connected to stdio server in 63ms
MCP server "claude-in-chrome": Connection established

Failing session (Mar 12, same version v2.1.74):

• Native host running (PID visible in ps aux)
• Socket created and connectable
• Extension installed in both Default and Profile 4
• Status bar shows "Claude in Chrome enabled"
• But: "Browser extension is not connected"

Key observations

1. It worked on Mar 2 finding the extension in Profile 4, then stopped working without any config changes
2. tengu_chrome_auto_enable is false in cachedGrowthBookFeatures (server-side flag). This may have changed between Mar 2 and now
3. Multiple Chrome profiles (8 profiles). Extension present in both Default and Profile 4
4. The native host creates the socket but the extension service worker never connects to it
5. No Claude Desktop installed (no native host conflict)

Native host config

{
  "name": "com.anthropic.claude_code_browser_extension",
  "description": "Claude Code Browser Extension Native Host",
  "path": "/home/user/.claude/chrome/chrome-native-host",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/"
  ]
}

Native host script

#!/bin/sh
exec "/home/user/.nvm/versions/node/v18.20.8/bin/node" "/home/user/.claude/local/node_modules/@anthropic-ai/claude-code/cli.js" --chrome-native-host

Expected behavior

tabs_context_mcp should return tab information and browser tools should work, as they did on Mar 2 with the same version.

Suspected cause

Either the tengu_chrome_auto_enable feature flag was flipped server-side between Mar 2-12, or the bridge handshake (wss://bridge.claudeusercontent.com) is rejecting connections that previously worked. The local native messaging chain is fully functional.