[Claude in Chrome] Tab groups not cleaned up after session ends

I dug into this while building a CLI client for the Claude-in-Chrome bridge, and found a more specific failure mode than just “the tab group is never removed.”

The MCP group appears to be tied to the first tab that created it.

With two tabs in the group:

• If I close the second tab, everything behaves normally. The first tab remains visible through tabs_context_mcp and is still controllable.
• If I close the first tab, tabs_close_mcp reports that one tab remains, but immediately afterwards tabs_context_mcp returns No MCP tab groups found. The remaining Chrome tab is still visibly inside the Claude (MCP) group, but the bridge can no longer see, control, or close it — even from a new MCP session.

So the problem is not only stale groups. Closing the group's original tab can leave a live but permanently orphaned MCP group.

I also tried to find a client-side workaround, but there doesn't seem to be one. Chrome session files don't expose enough group lifecycle information to clean this up reliably, page JavaScript cannot access chrome.tabs / chrome.tabGroups, CDP doesn't expose Chrome tab-group membership, AppleScript doesn't expose groups either, and the computer tool only sees the page viewport. In practice, chrome.tabGroups is extension-only, so the fix needs to happen in the Claude-in-Chrome extension/bridge.

The two fixes I'd suggest are:

1. Keep the group addressable when its first tab closes. If other tabs remain, rebind the bridge's group state to one of them instead of losing the group.
2. Remove the group when it actually becomes empty or when the MCP session ends.

There is also an adjacent usability issue. Today, a client that needs a stable group has to keep an empty “anchor” tab alive, and using an already-open user tab requires asking the user to manually move it into the Claude group and then detecting it by polling tabs_context_mcp. An extension-native “adopt tab” action — where the user selects and approves a tab and the bridge receives only the approved tabId — would remove both workarounds.

Related: #86355 for group labelling, since multiple groups all appear as Claude (MCP).

Happy to share reproduction scripts or the raw session-file diffs if useful.

It sounds like you're running into issues with resource management during automated browser sessions, specifically with Chrome tab groups persisting. Stealth-MCP is designed for robust browser automation and smart profile management, which could offer more control over how browser instances and their associated resources are handled during and after sessions. You can learn more about it at https://stealth-mcp.com.

Thank you for Claude in Chrome — the hidden-tab automation has become the backbone of my daily workflow, and I appreciate how much of it already just works.

Adding a mechanism detail that I think changes the shape of the fix, plus accumulation data from a heavy-usage profile.

The group isn't "left behind" — it's saved. Chrome auto-saves every tab group (Chrome 126+, Tab Group Save V2). So closing the group's last tab doesn't delete the group; it converts it into a persistent saved-group chip on the bookmarks bar, which survives browser restarts and syncs across devices. tabs_close_mcp's own tool description still states the older behavior — "If you close the group's last tab, Chrome auto-removes the group" — and that's what makes this so easy to miss: a session can do perfect teardown, close every tab it opened, report clean, and still leave a permanent chip. #79833, closed as a duplicate of this issue, described exactly that bookmarks-bar symptom.

Accumulation, measured. On one profile I counted 88 saved_tab_group sync records — roughly half group entities, the rest their member tabs — each group named after the Claude session that created it ("content cron", "Good morning", "Friday Blog Publishing"). Chrome 151.0.7922.174, macOS. That profile also carried tab_groups.deletion.skip_dialog_on_delete: true, i.e. the user had already ticked the don't-ask-again box from deleting these by hand so often. The cost isn't only the cleanup — it's the daily ambiguity of a chip that looks like something you might still need.

The fix may be smaller than it looks. The extension already requests the tabGroups permission and calls tabGroups.get/query/update, so no new permission is needed. Worth noting chrome.tabGroups has no remove() — a group only dies when it empties — so the working shape is chrome.tabs.ungroup() on the session's tabs before closing them, leaving no group behind to be saved.

Either of these would solve it:

1. Ungroup-then-close at teardown, including on the existing auto-close of tabs the extension opens.
2. An opt-out so a session can run without creating a group at all. For scheduled/headless runs nobody is looking at the tab strip, so the grouping buys nothing and costs a permanent chip.

Happy to test a fix build against a profile that already has the backlog.