Claude in Chrome: extension binds the Claude Code native host, host listens on its bridge socket, but the interactive CLI session never attaches → "Browser extension is not connected

Environment

• macOS (Darwin 25.5.0, Apple Silicon / arm64)
• Google Chrome 149.0.7827.54
• "Claude in Chrome" extension v1.0.74 (id fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Claude Code 2.1.161 (installed via native installer; versions present: 2.1.161, 2.1.159, 2.1.157; no current/latest symlink in ~/.local/share/claude/)
• Auth: Claude Max (subscription)
• Claude desktop app also installed (its native-messaging manifest was disabled during testing — see below)

Summary
mcp__claude-in-chrome__list_connected_browsers (and tabs_context_mcp) always report "Browser extension is not connected," even though the extension successfully connects to the Claude
Code native messaging host and that host is listening on its bridge socket. The interactive CLI session never attaches to the socket, so browser tools have nothing to talk to.

What works / is verified correct (ruled out as the cause)

• Auth is Claude Max (not an API key).
• Extension installed + enabled, v1.0.74 (≥ required 1.0.36).
• Native-host manifest com.anthropic.claude_code_browser_extension.json is enabled with correct name, path, and allowed_origins (the extension id).
• The wrapper ~/.claude/chrome/chrome-native-host execs a valid, current binary: ~/.local/share/claude/versions/2.1.161 --chrome-native-host.
• No version skew: both the interactive session and the spawned native host run 2.1.161 (confirmed via lsof txt).
• The competing Claude desktop app native-host manifest (com.anthropic.claude_browser_extension.json, which allows the same extension id) was renamed to .disabled, and the desktop app

was quit, to ensure the extension could only reach the Claude Code host.

Diagnosis (the key finding)
Launching with claude --chrome (rather than enabling mid-session with /chrome) gets the extension to bind the Claude Code host. Chrome then spawns:

<pid> /Users/<user>/.local/share/claude/versions/2.1.161 --chrome-native-host (parent: Google Chrome)

That native host creates and listens on a unix socket:

/tmp/claude-mcp-browser-bridge-<user>/<nativehost-pid>.sock (srw------- owned by the user)

However, the interactive claude --chrome session does not have that socket open (lsof on both PIDs shows no shared socket) — i.e., the session's "Claude in Chrome" MCP server never
connects to the bridge socket. Hence "not connected."

Suspected root cause: an ordering race. The socket is created only after the extension connects, which (with claude --chrome) happens after the session has already started. The session
does not appear to re-attach to the bridge socket when it later appears. Restarting the CLI while leaving Chrome (and the native host) alive is the next thing to try, but filing this
regardless.

Additional bug: Running /chrome → "Reconnect extension" mid-session repeatedly closes the active Chrome window and never establishes a bridge.

Steps to reproduce

1. macOS with both the Claude desktop app and Claude Code CLI installed, Claude Max auth, "Claude in Chrome" extension installed/enabled.
2. Ensure only the Claude Code native-host manifest is enabled (disable/remove the desktop one).
3. Fully quit Chrome. Start a session with claude --chrome. Open Chrome.
4. Observe: native host process spawns (parent = Chrome) and listens on /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock, but list_connected_browsers reports "Browser extension is not

connected."

Expected: the interactive session attaches to the native host's bridge socket and list_connected_browsers lists the browser.

Actual: native host listens; session never attaches; tools report "not connected."

Diagnostic commands used
pgrep -fl -- '--chrome-native-host'
ls -la /tmp/claude-mcp-browser-bridge-$USER/
lsof -p <nativehost-pid> # shows it listening on <pid>.sock
lsof -p <session-pid> # shows the session does NOT have that socket open

---