Bug report: Claude in Chrome: "Browser extension is not connected" despite fully healthy local native-messaging bridge

Summary

Every mcp__claude-in-chrome__* tool (including list_connected_browsers and switch_browser) returns:

Browser extension is not connected. Please ensure the Claude browser extension is installed and running, and that you are logged into claude.ai with the same account as Claude Code...

…even though the native-messaging host spawns correctly, creates its unix socket, and is listening. The Claude Code session never attaches to the bridge socket — only the native host process itself is ever connected to it.

Environment

• OS: macOS (Darwin 25.x), Apple Silicon
• Claude Code: 2.1.187 (reproduced on 2.1.178 first, then updated to 2.1.187 — same result)
• Install: single npm global under nvm (~/.nvm/versions/node/v22.17.0/.../@anthropic-ai/claude-code); claude symlinks to that exact claude.exe
• Launched as: claude --dangerously-skip-permissions / claude --continue
• Auth: claude.ai OAuth as lbwalton@gmail.com (NOT an API key; ANTHROPIC_API_KEY unset; no apiKeyHelper)
• Browser: Google Chrome (extension id fcoeoabgfenejglbffodgkkbkcdhcgfn), installed + signed in + pinned in the active profile

What was verified HEALTHY

• Native messaging manifest com.anthropic.claude_code_browser_extension.json present; path → ~/.claude/chrome/chrome-native-host; wrapper execs claude.exe --chrome-native-host; allowed_origins matches the extension id.
• Competing Claude Desktop native-messaging manifest renamed to .disabled so the extension targets Claude Code.
• Native host spawns on every extension "Connect" and creates /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock. lsof confirms the host is listening on its own socket.
• Extension is the correct id, signed in to claude.ai (side panel chat works), site access set to "On all sites".
• Only ONE Claude Code session running.
• Claude Code and the extension are the SAME account (lbwalton@gmail.com).
• Binary on both ends is the same single install (2.1.187).

Key diagnostic finding

A 60-second live monitor of the bridge socket directory, taken WHILE running /chrome → Reconnect, showed zero change: no new connection on the socket, no host respawn. lsof <socket> shows only the native host PID attached — the Claude Code session's MCP client never connects as a client. /chrome reconnect briefly opens a Chrome window that auto-closes and never reaches the native-messaging layer.

# representative state — host present + listening, session absent
$ pgrep -fl chrome-native-host
82687 .../claude.exe --chrome-native-host
$ lsof /tmp/claude-mcp-browser-bridge-<user>/82687.sock
COMMAND    PID  ...
claude.ex  82687  6u  unix   # <-- ONLY the host; no session client

Repro

1. Healthy install as above, one session, matching account.
2. Click the extension's Connect (host spawns, socket created).
3. Call any browser tool, or run /chrome → Reconnect.
4. Observe: "Browser extension is not connected"; socket never gains a second (session) connection.

Already attempted (no effect)

• Full machine restart.
• Full Chrome quit (Cmd+Q) + relaunch.
• Full Claude Code session quit + claude --continue.
• Extension uninstall + reinstall.
• Extension disable/enable + site access "On all sites".
• Killed stale/leftover native hosts; cleared the bridge dir.
• Updated Claude Code 2.1.178 → 2.1.187 via npm.
• list_connected_browsers and switch_browser both return the same "not connected" error.

Ask

What establishes the session-side attachment to the bridge socket, and why would a session on the latest version, same account, healthy host + socket, never connect? Is there an additional handshake/registration the session relies on that isn't happening here?