Cleanup

Cleanup

pstack's Worktree and simulator cleanup playbook is the method, and this skill wins where the two differ. When you remove a worktree yourself, use only git worktree remove --force, never rm -rf or git worktree prune. This skill adds what it lacks for this setup: the runtime's session list, session transcripts and running processes decide which worktrees are in use, uncommitted changes never keep a worktree, Next.js cache folders join the list, and the block's Autopilot rule lets the safe set go without asking. A card session lands its uncommitted changes in the checkout as a patch, so a leftover worktree's changes are usually there already, even when the checkout has edited them since. scripts/scan.mjs beside this file makes every verdict, so a rerun reaches the same one. Its --landed <worktree> mode checks that the checkout holds every change and ignored file of one worktree. In a pstack project, whose .agents/pstack.json names its plans directory, it counts only ignored files under <plans>/artifacts/, where a file counts once the checkout has its path, and skips commits only HEAD's reflog reaches, because there every other ignored file is build output or a copy and a landed squash leaves its originals in the reflog. Each file must match byte for byte, except a tracked file another landed patch also edited, whose hunks the checkout's copy must hold. A card session runs it right after its patch lands, before it deletes its own. Its --remove <worktree>... mode judges nothing. The chips sweep passes it the worktrees of the landed card sessions it archived, and the mode stops each process working in one, saves the uncommitted changes the checkout lacks as a patch, saves each commit no branch, tag or remote reaches as a second patch, and removes it. It keeps a worktree git does not list, a locked one, one outside the folders agents make worktrees in, one holding another worktree, the one it runs in, one whose commits git cannot list, one whose processes lsof cannot list and one git refuses to remove. The scan and --landed hold back a worktree with such a commit, which only its HEAD history keeps once a switch or reset leaves it, because the removal deletes that history. They hold it back only while the commit writes a file whose content neither the checkout's HEAD nor its upstream has and neither changed since, so the commits a squash landing leaves behind do not, and --delete saves them as a patch before it removes the worktree. --remove saves it instead, because a card session commits its work in its own worktree and lands the same change here as a patch.

/cleanup scan lists and removes nothing. /cleanup removes the safe set. /cleanup all removes it in every checkout beside this one, such as each repository in ~/git. Its steps 3 and 4 pass --repos <that folder> instead of --repo ., and the scan judges each checkout there that has linked worktrees against one session list. Schedule /cleanup all to run each day. One busy repository gained about ten subagent worktrees a day. du puts each at 2 GB or more, but on APFS a pnpm install clones the package store's files, so the space a worktree alone uses is mostly its builds and dev caches, 0.2 to 8 GB.

1. Record df -h <checkout>. On macOS, df -h / reports the read-only system volume, not the data volume that holds the checkout.
2. List every session, archived ones included, with the runtime's session tool, such as Claude Code desktop's list_sessions with include_archived and a limit above the session count. Save its JSON array to the run directory. Without a session list no worktree can be safe, so a runtime with no session tool removes only caches and run folders.
3. From the project's checkout, run node <this skill>/scripts/scan.mjs --repo . --sessions <that file> in the background, because it measures every folder with du. It prints one row per worktree and cache folder, SAFE, ASK or KEEP with its size and reason, and the count and size of each.
   • KEEP for a worktree: git lists it as locked, the scan runs in it, a running process such as a session, shell or dev server works in it, a running session, or one the owner pinned, claims it, or a server holds a cache inside it. A worktree no session claims stays while the session whose scratch folder holds it wrote its transcript in the last day, or, outside a scratch folder, while it changed in the last day. That clock reads the time of the newest entry in the worktree's HEAD reflog, not the reflog file's modification time, because git gc rewrites the reflog of every worktree at once. The scan also keeps it when lsof cannot answer.
   • SAFE for a worktree: it sits where agents make worktrees and nothing above keeps it. No session that claims it is running, or none claims it and it has been quiet for a day. A session left open but idle does not keep it. Its uncommitted changes do not keep it. --delete saves the ones the checkout lacks as a patch under the repository's git folder, in cleanup/, before it removes the worktree, and its branch stays. A worktree whose every change the checkout already holds gets no patch, because its card's landing patch is the record. A worktree whose folder is already gone is also SAFE, because only git's record of it goes, and so is one whose folder lost its .git file and holds no files. Agents make worktrees in the app's .claude/worktrees and a temp or scratch folder, and older runs left them in the run directory.
   • ASK for a worktree: it sits outside those folders, another worktree lives inside it, it holds a submodule or nested repository with changes, it holds a commit no branch, tag or remote reaches whose changes the checkout lacks, or its folder lost its .git file and still holds files, which git can no longer read.
   • KEEP for a cache: a running server holds its dev/lock or lock. Outside a run folder, a build output (.next or .next-plite) never goes, because next start may serve it. Its dev and cache folders, which Next recreates, get rows of their own instead: KEEP while a server holds the build output's lock or something wrote within two levels of the folder in the last day, and SAFE after that. Any other .next-* folder is judged whole: KEEP for a week after its last use when it holds a production build (BUILD_ID) or is a port's dev cache (.next-<port>), for an hour otherwise, and SAFE after that. A cache inside a safe worktree goes with that worktree.
   • A run folder is each folder in <plans>/artifacts/ of a pstack project, whose .agents/pstack.json names its plans directory. Each folder in an ignored .tmp/ at a checkout's root, where runs left scratch copies, is one too, in any project. It gets a row only when it holds an install or build (node_modules, .next, .next-* or .turbo) or nothing wrote it for a week. Its quiet time reads only file writes outside those folders. KEEP when a worktree lives inside it, a running process works in it or something wrote it in the last day. SAFE with expire, which deletes the whole folder, when nothing wrote it for a week and neither the ledger nor a decision log in <plans>/ changed that week names it, because a new row may still cite its files as proof. A clone inside it blocks expire when it holds commits no remote has, such as a stash or any commit of a clone with no remote, or when git cannot read it, such as a worktree copy its repository dropped. Such a folder is SAFE with strip while it holds installs or builds, and ASK after that. Before --delete expires a folder, it saves each clone's uncommitted changes as a patch under the repository's git folder, in cleanup/, as it does for a worktree's. The patch holds each file git does not ignore, every one of them in a repository with no commit yet, and the ignored ones, such as installs, builds and env copies, go with the folder. Otherwise SAFE with strip, which deletes only its installs and builds and keeps its logs. The scan never touches a file at the top of <plans>/artifacts/ or .tmp/, such as the ledger or a rendered plan page.
4. For /cleanup scan, report the table and stop. Otherwise save the session list again as step 2 does, then run the same command with --delete and the new file. It measures each safe item, judges it again, lists the running processes once more and saves a worktree's uncommitted changes the checkout lacks as a patch right before removing it, so a folder stays when a process started working in it, or a server took it, during the scan. A desktop session reopened with no process in the folder yet is the one case it cannot see. It removes a worktree with git worktree remove --force, and a failed removal turns that row into ASK. Never run git worktree prune or git stash.
5. List each ASK row for the owner with its path, size, reason and session title. Remove only the ones the owner names, with git worktree remove --force <path>. Lock each one the owner keeps with git worktree lock --reason "<why>" <path>, so later scans and the session-start hint skip it.
6. Record df -h <checkout> again and report the space freed from the two df readings, because du counts the hard links and APFS clones a package store shares once per folder. Then report what went and each row kept or asked, with its reason.

Run it once in each project checkout whose worktrees or caches the owner wants gone. A card session already removes its own worktree when its patch lands, as the chips Landing rule says, and in a project whose delivery is trunk every session removes its own once its task lands, so the scan mostly finds worktrees from before those rules, proof worktrees a run left behind, dev caches and subagent worktrees. Claude Code names a subagent's worktree agent-<id>, locks it while the subagent runs, and keeps it once the subagent has changed a file.

A next dev run spawns a detached process that flushes Next's telemetry and should exit within seconds. When it starts an esbuild service, as a Next config that loads @workflow builders does, it never exits, and the scan keeps the worktree it works in. If a KEEP row's processes have parent PID 1 and run next/dist/telemetry/detached-flush.js, stop them, run next telemetry disable once so no new ones start, and scan again.