Title: tabs_context_mcp returns "Browser extension is not connected" on every session's first call, despite extension and MCP tab group being confirmed active

## Summary
Every time I open a fresh Claude Code CLI session and the model calls mcp__claude-in-chrome__tabs_context_mcp, the call returns
the string "Browser extension is not connected. Please ensure the Claude browser extension is installed and running…" — even
though the Claude browser extension is connected and an MCP tab group with valid tabs is already open.

The false-disconnect happens ~5–10 times per working session. Effectively every attempt to attach to a running browser state
fails on first try.

## Environment

• macOS darwin (Apple Silicon)
• Chrome with Claude browser extension installed and showing connected state
• Claude Code CLI (claude-opus-4-7)
• MCP tab group pre-created by user and named "Claude (MCP)" with a working tab inside (e.g. http://localhost:8002/)

## Repro

1. Launch Chrome, sign in to claude.ai with the same account as Claude Code CLI.
2. Confirm the extension icon shows the connected/green state.
3. Open a tab inside the Claude (MCP) tab group, navigate it to any URL (e.g. http://localhost:8002/).
4. Start a fresh Claude Code CLI session.
5. Ask the assistant to connect / read the page / screenshot / etc.
6. The assistant calls mcp__claude-in-chrome__tabs_context_mcp.

Expected: returns { availableTabs: [...], tabGroupId: ... } listing the existing tab.

Actual: returns "Browser extension is not connected. Please ensure the Claude browser extension is installed and running
(https://claude.ai/chrome), and that you are logged into claude.ai with the same account as Claude Code. If this is your first
time connecting to Chrome, you may need to restart Chrome for the installation to take effect."

## Evidence it is a bridge-layer false negative (not a real disconnect)

• Extension icon in Chrome shows the connected state.
• Tab group "Claude (MCP)" exists, contains a live tab.
• Screenshot attached showing both.
• User has not restarted Chrome, re-signed in, or reinstalled the extension — the state they had at the end of the previous

working session is what the CLI now sees as disconnected.

• After some unclear trigger (subsequent call, short wait, sometimes a second session), the same tool call starts returning the

correct availableTabs. No user action changed.

## Model-side downstream damage
Historically, models treating this as a real "no tabs" result have followed the system-prompt default ("Otherwise, create a new
tab with tabs_create_mcp"). That creates a second tab at the same app origin, which for apps that enforce single-session
detection (e.g. WebMIDI apps) crashes the user's primary working tab. This has been a daily source of frustration for ~3 months
for the user reporting this.

A user-level workaround (instructing the model to always tabs_context_mcp first and never create new tabs) mitigates the crash
but cannot recover when the first tool call itself lies about connection state.

## Impact

• Blocks visual verification, UI testing, and browser-driven diagnosis on every session startup and at intermittent points within

a session.

• 5–10 false disconnects per working session.
• No self-service recovery available to the model at runtime (no reconnect/ping tool exposed).

## Ask

1. Investigate why tabs_context_mcp reports disconnected when the extension's actual WebSocket state is connected.
2. If the bridge legitimately drops, expose a reconnect or wait-for-connect tool so the model can recover without creating a

second tab.

1. Consider changing the default guidance ("Otherwise, create a new tab with tabs_create_mcp") to "first re-check

tabs_context_mcp" to reduce collateral damage for single-session apps.