claude-in-chrome: extension shows connected but list_connected_browsers/tabs_context_mcp stay empty

Description

The Chrome extension ("Claude in Chrome") shows as connected (correct claude.ai account, no console errors on the service worker) but the CLI-side MCP tools (tabs_context_mcp, list_connected_browsers) never see it, even after extensive troubleshooting.

Environment

• Claude Code CLI version: 2.1.220 (macOS)
• Extension version: 1.0.84 (Chrome Web Store, fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Auth: claude.ai account login (not API key)
• Two Claude Code CLI sessions were running concurrently on the machine (different iTerm tabs / PIDs)

Steps taken (chronological)

1. tabs_context_mcp initially failed with "Browser extension is not connected."
2. Fully quit and relaunched Chrome — no change.
3. Investigated on disk: found the extension was stuck on a delayed/idle install — Chrome's Secure Preferences showed the active path still pointing at 1.0.77_0 while 1.0.84_0 sat in idle_install_info (pending, waiting for the extension to go idle before Chrome would swap versions). This is a legitimate Chrome extension-update-pending-idle situation, not user error.
4. After another full quit (all Chrome processes confirmed gone via Activity Monitor) + relaunch, Secure Preferences confirmed the active version flipped to 1.0.84 and idle_install_info was cleared. Confirmed via:

``
python3 -c "import json; d=json.load(open('.../Secure Preferences')); print(d['extensions']['settings']['fcoeoabgfenejglbffodgkkbkcdhcgfn']['path'])"
# -> fcoeoabgfenejglbffodgkkbkcdhcgfn/1.0.84_0
``

1. tabs_context_mcp still reported not connected.
2. Verified via lsof that the exact Claude Code CLI process backing this session (confirmed by walking the PPID chain from the Bash tool's own shell up to the claude process) had a long-lived ESTABLISHED TCP connection to bridge.claudeusercontent.com (resolved IP 160.79.104.10:443) — so the CLI-side transport to the bridge was up throughout.
3. Discovered the user had two concurrent Claude Code CLI sessions open (different iTerm tabs/PIDs). Checked the extension's own popup — it was paired to the other session, not the one making the tool calls. User switched the pairing in the extension popup to the correct session.
4. tabs_context_mcp still failed after switching pairing in the popup.
5. Loaded list_connected_browsers (MCP tool) — returned [] (empty), even though the extension popup shows connected with the right account.
6. Tried switch_browser — returned "No other browsers available to switch to." (no confirmation prompt appeared / nothing to select).
7. Ruled out an account mismatch: confirmed the CLI session is authenticated via claude.ai account login (not a bare API key), matching the account the extension popup shows.
8. Checked the extension's service worker console via chrome://extensions → Inspect views → service worker: no errors logged.
9. Did a full Chrome quit/relaunch again as a final attempt — no change. list_connected_browsers still [], tabs_context_mcp still reports not connected.

Expected behavior

Once the extension popup shows "connected" to the correct account and is paired to the active CLI session, list_connected_browsers should show that browser, and tabs_context_mcp / other browser automation tools should work.

Actual behavior

list_connected_browsers returns [] persistently, and tabs_context_mcp reports the extension as not connected, despite:

• Correct extension version (1.0.84, confirmed via Chrome's Secure Preferences)
• Correct account in the extension popup
• Active CLI-side transport socket to the bridge server
• Pairing explicitly switched to the correct session in the extension popup
• No errors in the extension's service worker console
• Multiple full Chrome quit/relaunch cycles

This looks like a backend-side pairing/registry issue (the extension successfully connects to some backend endpoint, but the CLI-facing "connected browsers" registry for this account never reflects it) rather than anything fixable client-side.

Note on multiple concurrent CLI sessions

Worth double-checking whether having two Claude Code CLI sessions open concurrently on the same machine/account could leave the pairing registry in a bad state (e.g., the second session's pairing request not correctly registering, or the first session's stale entry blocking it).