[Claude in Chrome / macOS] Service worker restarts drop session→tab-group mapping every few minutes; timed-out tool calls actually executed

Summary

The Claude in Chrome extension's service worker appears to restart every few minutes and lose its in-memory session→tab-group mapping. Sessions doing browser automation repeatedly get No tab group exists for this session / Tab <id> no longer exists, and tool calls "time out" even though the action actually executed in Chrome. One session observed its tab group destroyed and recreated 7 times in a single evening on a single-session workload with no concurrency.

Related but distinct from #87327 (state lost after exactly one call, Windows) and #69542 (new group per session). Here the mapping is lost mid-session, repeatedly, on a timer-like cadence, on macOS.

Environment

• macOS 26.6.1 (Darwin 25.6.0), Apple Silicon
• Google Chrome 151.0.7922.140, single profile running
• Claude extension v1.0.85 (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Claude desktop app 1.30096.5 (Cowork sessions) + Claude Code CLI sessions, connecting via the cloud bridge (wss://bridge.claudeusercontent.com/chrome/...)
• Chrome Memory Saver fully disabled and Chrome restarted before the observations below, so tab discarding is ruled out. The native messaging host is stable (its log only shows disconnects when Chrome itself quits).

Symptoms

1. tabs_context_mcp intermittently returns No tab group exists for this session minutes after the same session successfully created a group and used it.
2. Tab <id> no longer exists for a tab the session created moments earlier and never closed.
3. Tool calls time out (60–150s) but the action actually executed: a navigate to example.org returned "did not respond in time" twice, yet the page was loaded in Chrome — the response was lost, not the command. Desktop log shows the matching pattern: instant ~30ms tool errors, then Tool call timeout ... pending calls: 0.
4. Desktop main.log recorded ~5,800 [claude-in-chrome] Chrome extension connected to bridge lines in one day (a connected/ensureConnected/already-connected triple roughly every 2s while sessions are active).

Log excerpts (desktop main.log):

15:11:07 [warn] [claude-in-chrome] Tool call timeout: tabs_context_mcp (8f10e689) after 60001ms, pending calls: 0
15:13:52 [warn] [claude-in-chrome] Tool call error: computer (09858934) after 31ms
15:20:05 [warn] [claude-in-chrome] Tool call timeout: computer (c3f5040f) after 90001ms, pending calls: 0

One session's tab-group churn in a single evening (each new id after a "no longer exists" or timeout):
2058605809 → 989395048 → 1558872276 → 1881120855 → 2025759118 → 1496948006 → 133702607

What it is NOT

We ran a deliberate two-session concurrency test (two sessions driving the same extension instance simultaneously, one tab each, example.com vs example.org). Per-session tab-group isolation worked correctly — distinct groups, zero cross-visibility, zero cross-tab actions. Then both sessions' groups vanished spontaneously mid-test with neither session (nor the user) closing anything. So this is state loss in the extension, not sessions interfering, and with Memory Saver disabled it is not tab discarding.

Expected

• The session→tab-group mapping should survive service worker restarts (persist to chrome.storage.session / re-derive from the tab group on wake), or the extension should keep the worker alive while tool sessions are active.
• A tool call whose action executed should not be reported as a timeout; at minimum the reply should be re-associated after the worker restarts.

Repro

1. macOS + Chrome + extension versions above; connect a desktop/Cowork or CLI session.
2. Create a tab group (tabs_context_mcp {createIfEmpty: true}), navigate somewhere, then keep the session going with intermittent browser calls over 10–30 minutes.
3. Observe No tab group exists for this session / Tab N no longer exists recur, and occasional timeouts on calls that visibly executed in Chrome.