Claude in Chrome: pairing state is invisible and account-coupling is undocumented — an evening lost to indistinguishable empty states
Summary
Two related UX gaps in the Claude in Chrome extension + mcp__claude-in-chrome__* bridge cost a full working evening. Both are observability problems, not functional bugs — the system worked once we reverse-engineered its rules.
Environment
- Claude Code (background session) on macOS (Darwin 25.5), multiple Anthropic accounts in use across one machine
- Chrome extension current as of 2026-08-05
Problem 1: list_connected_browsers returns [] for at least four distinct states
Not installed · installed but signed out · signed into the WRONG Anthropic account (≠ the Claude Code session's account) · signed in correctly but not yet re-registered (needs extension toggle) or first-run consent not yet accepted. All look identical from the agent side, so the model can only guess which human instruction to give. Tonight's sequence to revive pairing was: options-page sign-in (toolbar popup sign-in was NOT sufficient) → toggle extension off/on → click the 'Before you start / I understand' consent. Nothing surfaced which step was missing at any point.
Ask: expose pairing diagnostics to the tool call — e.g. {installed, signedInAccount, accountMatches, consentAccepted, registered} — or at minimum distinct error strings.
Problem 2: account coupling is a silent hard requirement
The extension pairs only when its signed-in account equals the Claude Code session's account. With multiple accounts (rate-limit juggling across a small team), this is the #1 silent killer — and a claude.ai site logout in the same browser also severs the extension's login, so a user switching claude.ai workspaces can unknowingly kill a live pairing mid-session.
Ask: document the account-coupling requirement prominently; warn in the extension UI when its account differs from an active local Claude Code session; don't couple the extension's session to claude.ai tab logouts.
Problem 3 (minor, related): chrome-devtools MCP automation Chrome captures the Dock icon
While a puppeteer-profile automation Chrome (spawned by chrome-devtools MCP) is running and the user's real Chrome is closed, clicking Chrome in the macOS Dock foregrounds the automation instance — the user experiences 'Chrome is possessed / I can't open a regular session', and Google blocks sign-ins inside it. A distinct app name/icon (or auto-quit when idle) would prevent real users fighting robot browsers.
Impact
An experienced daily-driver user + agent spent ~90 minutes across an evening on what was ultimately three invisible state mismatches. Everything works when the rules are known; the rules are currently archaeology.
🤖 Filed by Claude Code on the user's explicit request.