Claude in Chrome: MCP tab group lost between tool calls — recovery orphans a new tab each time (~15 orphaned groups/session); add option to work in a single plain tab

Summary

During browser-automation sessions, the Claude in Chrome extension repeatedly loses its MCP tab group between tool calls. Every recovery (tabs_context_mcp {createIfEmpty: true}) mints a brand-new tab group and orphans the previous tab. Over one working session this accumulated ~15 orphaned "Claude" tab groups in the tab bar (screenshot available), and made every multi-step flow (e.g. filling a form across two tool calls) unreliable.

Environment

• Claude Code 2.1.241 (macOS CLI)
• Google Chrome 151.0.7922.174, macOS 26.6.2 (Apple Silicon)
• Claude in Chrome extension (current as of 2026-08-24)

Repro / observed behavior

1. tabs_context_mcp {createIfEmpty: true} → returns a tab group + tabId. Works.
2. Perform one browser_batch (navigate + JS + screenshot) on that tabId. Works.
3. On the next tool call (same conversation, seconds later), the extension answers either:

• Couldn't determine which page this action targets. Re-read tabs_context_mcp and try again., or
• Failed to query tabs: No group with id: <id> (often 2–4 times in a row with different ids before a call succeeds).

1. The only way forward is createIfEmpty: true again → new group, new tab; the previous tab stays open, orphaned, un-adoptable.

The old tab is still alive in Chrome and on the right page — the extension has just lost its binding to it. Frequency in our session: nearly every turn boundary; batched calls (browser_batch) succeed internally, so the loss seems to happen while the extension is idle between MCP calls (service-worker suspension?).

Impact

• Any flow that needs a result from one call to feed the next (e.g. find → file_upload with the returned ref) fails almost deterministically, because the group dies between the two calls.
• The user's tab bar fills with orphaned "Claude" groups (~15 in one session).

Expected

• The extension should re-attach to its existing tab/group after a service-worker restart (persist the binding), instead of failing the call and forcing a fresh group.
• At minimum, createIfEmpty should adopt a still-open orphan tab from the same conversation rather than opening another one.

Feature request (related)

Please add an option to not use tab groups at all (and/or reuse a single plain tab per conversation): e.g. a setting like "tabGroups": false that makes the extension open one ordinary tab, keep working in that same tab for the whole session, and navigate it in place. The current group-per-recovery behavior is what turns a transient binding loss into permanent tab-bar clutter.

Workarounds we used

• Cram entire flows into single browser_batch calls (works until the flow needs a dynamic ref between calls).
• Retry tabs_context_mcp 2–4× until it sticks.
• Periodically ask the user to close the orphaned groups and restart Chrome.