[Bug]: Every session leaves a persistent "BrowserSkill" saved tab group in the bookmarks bar (Windows, 0.4.0) #535

BrowserSkill Version or Commit

0.4.0 (protocol 1.7), extension 0.4.0

Operating System

Windows

OS Details and Architecture

Windows 11 24H2 (Build 26100) x64

Installation Method

Built-in auto-updater (0.3.2 → 0.4.0 on 2026-10-30 12:25). Binary at ~/.local/bin/bsk.exe.

Browser and Browser Extension Version

QQ Browser 22.3 (Chromium 156) / Extension 0.4.0 (MV3). Also reproduced on Google Chrome 156.

Exact Command or API Call

bsk session start --json --no-focus
bsk navigate "https://www.qq.com" --session <id>
bsk session stop <id>

Minimal Reproduction Steps

1. bsk session start --json --no-focus → an Agent Window opens and its tabs are grouped under an orange BrowserSkill tab group (this part works as intended).
2. bsk session stop <id> → the Agent Window closes.
3. Look at the left end of the bookmarks bar: a new orange saved tab group chip titled BrowserSkill is now persisted there. It survives browser restarts.
4. Repeat → +1 chip per session.

Four teardown paths measured, each exactly +1 chip (verified by diffing screenshots of the bookmarks bar):

• session start then session stop immediately (tab still about:blank, no navigation at all): +1
• session stop after navigate: +1
• tab close <last-agent-tab-id> (window auto-closes, session auto-removed) with no explicit stop: +1
• session stop --all: +1 per session

So no client-side teardown sequence avoids it; --no-focus makes no difference either.

Expected Behavior

Ending a session should leave no trace in the user's browser UI. An automation session is transient by definition; once the Agent Window is gone, the tab group should be gone with it.

Actual Behavior

Each session is persisted as a saved tab group, rendered as a chip at the left end of the bookmarks bar, permanently. On Windows this is far more intrusive than the in-window leftover described in #534:

• It occupies the leftmost slot of the bookmarks bar, pushing the user's own bookmarks aside.
• It is visible during all normal browsing, not only while a session exists.
• It cannot be removed programmatically: chrome.tabGroups exposes no delete API, the group has no tabs left to move out, and chrome.bookmarks.removeTree would be required — but the extension does not request the bookmarks permission. Manual right-click → Remove group is the only way, one chip at a time.
• A normal working day accumulates 6+ chips (observed), each needing manual removal.

Root cause appears to be in background.js:

chrome.tabGroups.update(n, { title: 'BrowserSkill', color: 'orange', ... })

The group is created per Agent Window and never ungrouped before the window is disposed, so Chromium treats it as a user-created saved group and persists it. The Automation settings expose only confirmTabBorrow / requestHelpEnabled; the title and color are hard-coded and grouping cannot be disabled.

Relevant Logs / Diagnostics Output

2026-10-31T03:54:20.780412Z  INFO bsk::daemon::start: daemon ready pid=24404 ws_port=52800
2026-10-31T03:54:21.168766Z  INFO bsk::daemon::ws: browser connected id=<redacted> name=chrome generation=1
2026-10-31T03:54:49.197998Z  INFO bsk::daemon::ws: session removed: user closed Agent Window session=<redacted>

bsk doctor reports all checks ok, so this is not an environment fault.

Is this a regression?

Yes

Last Known Working Version (if regression)

0.3.2 — same machine, same browser, same workflow, no chip was ever left behind. The behaviour started right after the automatic 0.3.2 → 0.4.0 update on 2026-10-30.

Additional Context

Related: #534 (duplicate same-named groups stacking up inside the Agent Window after an MV3 service-worker restart, macOS). This is a different and more severe symptom on Windows: even a clean single-shot session that never restarts its worker leaves a permanent saved group in the bookmarks bar.

Suggested fixes, in order of preference:

1. Ungroup before disposing the window — call chrome.tabs.ungroup() on every tab the session grouped, before the window is removed. Empty groups are not persisted, so the chip never appears. This also fixes the [Bug]: Duplicate "BrowserSkill" tab groups stack up in the same Agent Window after the MV3 service worker restarts | 同一 Agent Window 在 Service Worker 重启后会叠加多个同名分组 #534 accumulation.
2. Skip grouping for automation entirely — the title/color carry no information for the user.
3. At minimum, an opt-out switch in Automation settings ("Group agent tabs").
4. Document a cleanup path for already-persisted chips.

Impact: this contradicts the README promise — "use your real, logged-in browser without interrupting your work". Every task visibly pollutes the user's everyday browser UI and demands manual cleanup afterwards.