[FEATURE] Auto-cleanup Chrome tab groups when Claude in Chrome sessions end

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

re open

still occurring

This is really annoying. Multiple Claude tab groups are piling up, and no way to manage them. +1 for this feature request!

+1 on prioritizing this — it’s a pretty significant usability gap right now.

In addition to prioritization, it would be really helpful to have an option to disable or control automatic group creation. The current behavior can quickly lead to cluttered or unintuitive organization, especially in larger or iterative workflows.

A simple solution could be:

• A toggle to turn off auto group creation entirely, or
• More granular controls (e.g., only group above a certain threshold, or manual grouping)

Same issue here. One thing I haven't seen mentioned: the tab group status icons (✅/⏳/❌) others reported no longer appear — orphaned groups just show grey square emojis now.

is there any stop gap solutions? seems you need to call chrome API

This Chrome extension will auto close tab groups, and it doesn't seem to break Claude. I've used it with the side panel and Claude Code terminal. So far no problems.

https://chromewebstore.google.com/detail/cfbnfkpaoldidigecaidbidijnhbgbll?utm_source=item-share-cb

Yes, this is annoying to me as well.

Super annoying - please fix this

hey folks, just use official chrome MCP https://github.com/ChromeDevTools/chrome-devtools-mcp rather than the Claude chrome extension, no problem on that one

Experiencing this in production with Nuvaus (growth automation platform built on Claude Code). Over multiple sessions, tab groups accumulate rapidly and consume significant RAM. This is a real blocker for continuous integration workflows where Claude Code runs frequently. Auto-cleanup on session end would be critical for production reliability.

any progress on this matter? Really impairs the UX when working with the extension, having previous open Tabs grouped up all the time.

Also finding it really annoying and makes me not want to use the extension unless absolutely necessary.

This is really annoying, my chrome is full of claude mcp tab groups and i have to manually remove them each time. I guess this would be an easy fix: Either create one single group and reuse, or just close the group after session ends (with a hook, and maybe with a timeout).

This is super annoying for scheduled tasks as you end up with lots of useless tab groups cluttering the browser. Please can fix it so that it is possible for it to clean up after itself. I get that you might not want it to always clean up when finished in case the user needs to inspect after a failed run. But it should at least have the ability to clean up if that is explictly part of its task.

This problem is exacerbated by using Claude Cowork which doesn't reuse it's own tab groups and just keeps spawning new ones over and over again and there's no good way to clean them out of the browser.

Facing this too. I use the Claude in Chrome integration with Claude Code (claude --chrome) for live debugging, and every new session spins up a fresh "Claude" tab group instead of reusing the existing one. After a day of work I end up with a stack of orphaned groups that I have to right-click → "Close group" one by one.

Beyond the clutter, the bigger pain is the visibility model: since only tabs inside Claude's group are visible to it, tabs I prepared in a previous session's group aren't seen by the new session, so I have to keep re-dragging tabs into the current group.

Two things that would fully solve it for me:

• Reuse an existing "Claude" tab group on reconnect/new session instead of creating a new one
• Auto-close or ungroup on normal session end (and ideally a claude command to list/clean up orphaned groups)

Environment:

• Claude Code 2.1.162 (latest)
• Chrome (latest)

Possibly related: #23861 and #15193.

This is a major impediment to working with Chrome-based browsers. I have to disable this and use other means that are not as good because my browser window gets overwhelming clutter from these tab groups. Hoping for a fix...

I am not sure how this got labeled a FEATURE. Are you saying it's normal behavior to do this and the 'FEATURE' is a toggle to turn it off?

We hit this from the cleanup side and ran into a hard wall worth flagging.

I built a small MV3 extension to vacuum up the leftover Claude / Claude (MCP) tab groups. It works fine for open groups (close their tabs and Chrome removes the group). But the ones that actually pile up over a day of sessions end up as Chrome saved tab groups — the chips pinned in the bookmarks bar that have no open tabs — and those cannot be removed by any extension:

• chrome.tabGroups.query() does not return saved/closed groups, and there is no delete API for them (API ref).
• This is an acknowledged gap on the Chromium extensions list with no current workaround.

So a third-party extension genuinely can't clean these up — it has to be fixed where they're created. The practical fix is on the Claude-in-Chrome / Cowork side: reuse a single session group and/or close the group's tabs when the session ends, so Chrome never persists a saved chip in the first place. Today the only recourse is manually right-clicking each chip → Delete group, which doesn't scale when every new session spawns another group.

🤖 _This comment was written by Claude Code_

+1 — hitting this daily. My tab strip currently has ~10 orphaned "Claude" groups from past sessions.

Worth noting the cleanup can't be done from within Claude Code today: the claude-in-chrome MCP tools (tabs_close_mcp) are scoped to the current session's own tab group, so a session can't reach groups left behind by earlier sessions, and SessionEnd/Stop hooks run shell commands that can't touch Chrome tab state. So the extension itself is the only place this can be fixed — either auto-close on clean session end or a "clean up orphaned Claude groups" action in the extension menu would cover it.

🤖 Generated with Claude Code

+1. Scheduled and unattended runs make this worse: every cron-triggered session leaves another saved "Claude" chip, so the pile grows even when nobody is at the browser. And as @caffodian found, saved groups are unreachable through the extension API, so cleanup after the fact cannot be automated by anyone. The fix has to live in the extension itself: close or ungroup on clean session end, or a setting to skip group creation entirely.

+1 on macOS. This UX issue can potentially lead to lost work.

I keep many Chrome windows open, each scoped to a different workstream, and new sessions land in whichever window was focused last. So the tab groups are opened across every window such that when I go to tidy up there's nothing obvious in the tab strip that distinguishes a group belonging to a running session from a stale one. I've closed active sessions by mistake doing this more than once.

As of v2.1.221, Claude in Chrome closes the browser tabs it opens once it no longer needs them, so tab groups no longer pile up after sessions end (changelog). Please update and let us know if you still see orphaned groups.

Closing as shipped.

🤖 Generated with Claude Code

@bcherny, thanks for the fix. Seems to be working now.

No orphaned groups on 2.1.233. Thanks @bcherny for the quick turnaround, and for all the great work on Claude Code.

Thanks, @bcherny , this looks good.

When I open the Claude extension on a tab, and then close it when I'm done, it keeps the tab group and ungroup instantly recreates the tab group. There's no "stop" button in Claude so I can't tell it "let's close this session". Only solution at the moment is to disable the Claude extension, ungroup the tab group, then re-enable.

Still occurring on Claude desktop app 1.34493.1, macOS (Darwin 24.6.0). I came here to file a new issue and stopped when the duplicate detector surfaced this one; adding evidence instead. Two things I have not seen named in this thread or its duplicates.

1. A correction to the root-cause theory in #83156.

That comment argues tabs_close_mcp is missing from the recommended tool-preload set, so it never enters the model's context. I checked my current version and that is no longer true: the claude-in-chrome MCP server instructions now list a core set of tabs_context_mcp, navigate, computer, read_page, tabs_create_mcp, tabs_close_mcp, with tabs_close_mcp included.

But the leak still happens, and my own session shows the surviving mechanism. My first preload call was a hand-typed selection that silently omitted tabs_close_mcp; I only loaded it later, in a separate call, once I explicitly went looking for it. So models drift from the documented core set when composing that selection by hand, and when the close tool is absent from context there is nothing to signal its absence. Fixing the docs did not fix the behavior, which argues the cleanup cannot live in an instruction at all.

2. The cross-group scoping, now actually tested rather than inferred.

I originally wrote this section from the tool list alone, which was sloppy of me, so I ran the real test with a second concurrent session. It created a blank throwaway tab in its own group and gave me the id. From my session:

tabs_close_mcp(tabId: 1656920540)
-> Tab 1656920540 is not in this session's tab group.
   Only tabs visible to this session can be closed.
   Call tabs_context_mcp to see closable tabs.

Confirmed, with the actual error: a running session cannot close another session's tabs, and tabs_context_mcp will not even enumerate them. So once a session ends, its tabs are reachable by exactly one actor: the human, by hand, one tab at a time.

3. A downstream harm that is worse than the clutter.

Because both tools are group-scoped and nothing in the surface reaches further, a session that never loaded the close tool cannot distinguish "I lack this capability" from "this capability does not exist."

The result, in a 20-session workflow: sessions told my user outright that Claude cannot close its own tabs. That is false, and I verified it false today in a single call. She believed it, because it came from several sessions independently, and spent weeks closing orphaned tabs by hand while every running session was structurally incapable of helping. Her words today, on seeing a session finally close one: "I was told be previous claude's that you all couldnt close your tabs, but now I'm seeing it done."

So the cost is not only accumulated tab groups. This configuration manufactures confident false statements about the product's capabilities, which the user then reasonably plans around.

Suggestion, unchanged from the original request: close the group when the session ends. Any instruction-level fix is unenforceable precisely when it matters most, which is after the session is gone. Failing that, making orphaned groups enumerable and closable by a running session would at least let a cleanup session sweep, instead of leaving the human as the only actor who can see the whole pile.