Show HN: Chrome tab group cleaner for Claude Code created tab groups

Franz Enzenhofer released chrome-tab-group-cleaner, an open-source tool that bulk-deletes saved tab groups in Chrome, addressing the 71 saved groups left behind by Claude Code in his browser. The tool, available as a Claude Code skill or CLI, requires Node 20+ and one runtime dependency, and it backs up the entire store before each delete. It can also handle orphaned tab entities and sync tombstones, though the developer notes that tombstone acceptance by Chrome builds is not verified against a real account.

Chrome has no bulk delete for saved tab groups. This is one. 71 saved groups, 70 of them left behind by Claude in Chrome. Chrome removes them one right-click at a time. After delete --claude --orphans --restart. The one group that is not Claude's survives. As a Claude Code skill - the repo is the skill: git clone https://github.com/franzenzenhofer/chrome-tab-group-cleaner.git \ ~/.claude/skills/chrome-tab-group-cleaner cd ~/.claude/skills/chrome-tab-group-cleaner && npm install && npm run build Then ask for it: "get rid of all these Claude tab groups" . Rather have your agent read it first? Paste this into Claude Code instead: Install https://github.com/franzenzenhofer/chrome-tab-group-cleaner as a global Claude Code skill. First clone it somewhere temporary and read SKILL.md, README.md and every file in src/, then tell me what it does, what it writes to, and anything you find questionable - it deletes records from Chrome's profile database and can quit my browser. If it looks wrong, stop and say so instead of installing. If it checks out: clone it to ~/.claude/skills/chrome-tab-group-cleaner, run npm install && npm run gates, and show me node dist/cli.js list --all-profiles . Never delete without a --dry-run first, never quit my browser without telling me. As a plain CLI: clone anywhere, npm install && npm run build , then node dist/cli.js --help . Node 20+, one runtime dependency. chrome-tab-group-cleaner list --all-profiles -v what is there chrome-tab-group-cleaner delete --claude --dry-run what would go chrome-tab-group-cleaner delete --claude --orphans --restart chrome-tab-group-cleaner restore --backup ~/.chrome-tab-group-cleaner/backups/Default-... Pick groups with --all , --claude , --match <text or --regex <pattern . Then --browser chrome|chromium|brave|edge , --profile <dir , --all-profiles , --orphans , --dry-run , --restart , --sync-tombstone . The browser must be quit for a delete: the store is locked, and a live browser rewrites it from memory on exit. --restart quits it and reopens your tabs. Every delete backs the whole store up first; restore puts it back. <user data /<Profile /Sync Data/LevelDB one key per entity: saved tab group-dt-<uuid { 1: schema version, 2: SavedTabGroupSpecifics } SavedTabGroupSpecifics { 1: guid, 2: created µs, 3: updated µs, 4: group, 5: tab } group { 2: title, 3: color, 4: position } tab { 1: group guid, 2: position, 3: url, 4: title } A group is a group entity plus its tab entities - delete only the group and the tabs linger as orphans, which is how Chrome leaves them too --orphans sweeps those . src/proto.ts reads this wire format directly, no protobuf dependency. A profile that syncs tab groups re-downloads a local delete, so delete refuses it. --sync-tombstone commits the deletion instead: the data record goes, its sync pb::EntityMetadata stays with is deleted = 1 and sequence number = acked sequence number + 1 , which the sync processor reads as a pending commit and sends to the account. 1 client tag hash 2 server id 3 is deleted 4 sequence number 5 acked sequence number 6 server version 7 creation time ms 8 modification time ms 9 specifics hash Those bytes are covered by tests, and the field numbers were read out of a live store. Whether a given Chrome build accepts a tombstone it did not write itself is not verified against a real account - worst case, the groups come back. npm run gates - typecheck, lint, test, build. Tests build real LevelDB stores and read them back, no mocks. MIT