claude-in-chrome: extension connection drops after exactly one successful tool call (tab group state lost)

Summary

The claude-in-chrome browser extension consistently loses its connection state after
exactly one successful tool call. Reconnecting (tabs_context_mcp with createIfEmpty: true)
sometimes succeeds, but the very next tool call in the same session fails with either:

• Failed to query tabs: No group with id: <random-id> (a different random id each time)
• Couldn't determine which page this action targets. Re-read tabs_context_mcp and try again.

This makes any multi-step browser automation (navigate → click → screenshot, etc.) unreliable —
every single tool call after the first requires a fresh tabs_context_mcp reconnect, and even
reconnecting itself frequently fails 3+ times in a row before succeeding.

Environment

• OS: Windows 11 Home 10.0.26200
• Chrome version: 151.0.7922.138
• Claude Code CLI (harness)

Console errors observed

Captured from the extension's service worker console (chrome://extensions → service worker):

Unchecked runtime.lastError: Debugger is not attached to the tab with id: <tabId>.
mcpPermissions-192xiXNg.js:2 WebSocket connection to
'wss://bridge.claudeusercontent.com/chrome/<uuid>' failed:
Error in connection establishment: net::ERR_NAME_NOT_RESOLVED

Troubleshooting already ruled out

• Third-party security software: disabled ALYac (Korean AV) real-time protection + web

shield entirely — no change.

• System memory pressure: freed memory by closing unused Chrome tabs (Chrome process count

46→17, free system memory 3.4GB→4.8GB) — connection reliability improved slightly but the
same "works once, fails on next call" pattern persisted.

• VPN/proxy software: none running.
• Multiple Chrome profiles: only one profile in use.
• DNS resolution: bridge.claudeusercontent.com resolves correctly via both nslookup and

Resolve-DnsName (→ 160.79.104.10 / 2607:6bc0::10).

• Raw TCP connectivity: Test-NetConnection bridge.claudeusercontent.com -Port 443 succeeds.
• Chrome Secure DNS provider: switched to a public resolver (Cloudflare) — no change.

Suspected root cause

Given DNS/network connectivity to the bridge host checks out fine at the OS level, but the
extension's own WebSocket to bridge.claudeusercontent.com intermittently fails with
ERR_NAME_NOT_RESOLVED, and tab-group state is lost every time this happens, it looks like the
extension's service worker (MV3) is being evicted/restarted between tool calls — likely because
its keep-alive WebSocket connection isn't reconnecting reliably — and its in-memory tab-group
map isn't being restored/persisted (e.g. via chrome.storage) across that restart.

Steps to reproduce

1. Open Chrome with the claude-in-chrome extension connected.
2. From Claude Code, call tabs_context_mcp with createIfEmpty: true — succeeds, returns a

tabGroupId.

1. Immediately call any other browser tool (e.g. navigate, computer screenshot) using a

tab from that group — usually succeeds once.

1. Call a second tool action right after — fails with "Failed to query tabs: No group with id:

..." or "Couldn't determine which page this action targets."

1. Repeat tabs_context_mcp — sometimes succeeds immediately, sometimes needs 3-5 retries.