9 Types of Disk Junk Left Behind by Parallel AI Coding Agents and Cleanup Commands

When multiple AI coding agents run tasks simultaneously, the disk quickly fills up with all kinds of leftovers. Claude Code, Codex, and Hermes IDE each have their own cleanup mechanisms, but none of them can manage what the others leave behind. A developer on dev.to systematically laid out 9 common types of residue and provided a complete command list for inspecting first, then deleting.

The core problem: every agent creates folders, branches, or processes when invoking tools, and nothing comes back to clean up after the task ends. Worktrees stay locked, branches go unmerged, dev servers hold onto ports, and node_modules gets duplicated in every worktree. Individually these seem harmless, but after a few weeks they start eating disk space, hogging ports, and preventing git gc from reclaiming objects that should be freed.

Worktrees: Folders, Records, and Locks

Abandoned worktree folders. Start with git worktree list -v to list all worktrees and their locked or prunable status. Codex keeps the most recent 15 worktrees by default and deletes older ones when exceeded; Claude Code automatically removes clean worktrees when exiting unnamed interactive sessions, and prompts first for named sessions. But claude -p --worktree has no exit prompt — its worktree stays on disk until a later session's cleanup scan releases it.

For folders you've confirmed are no longer needed, remove them via git so the record is cleared too: git worktree remove ../fix-login. Git only removes clean worktrees — no untracked files, no modified tracked files. Dirty worktrees need --force, and locked ones need --force twice. This refusal is a safety mechanism — open the folder first, commit or copy what you need to keep, then decide.

Stale records and locks. After deleting a worktree folder with rm -rf, git still keeps a record under $GIT_DIR/worktrees, and git worktree list will mark it as prunable. Dry-run first, then prune: git worktree prune --dry-run --verbose, then git worktree prune --verbose. git gc will eventually do this too, but with a three-month grace period by default.

Locks are the other half of the problem. Claude Code locks worktrees while agents are running and releases them when they finish. Locks left by killed sessions wait until a later scan to be released. git worktree list --porcelain shows a locked line for each lock. Once you've confirmed nothing is running, git worktree unlock <path> releases it.

---

A worktree is a Git mechanism that allows checking out multiple branches into different directories under the same repository. Each worktree has its own working directory and HEAD, but shares the same .git object store and ref database. This lets multiple AI agents work in parallel without interfering with each other: Agent A fixes a login issue in ../fix-login while Agent B develops a new feature in ../feature-x, both using the same commit history. The cost is that each worktree needs its own dependency install, build artifacts, and temp files. When agent tasks end without cleanup, these worktree directories keep consuming disk space. git worktree list lists all worktrees, git worktree remove safely removes them, and git worktree prune cleans up records of already-deleted worktrees. Understanding worktree's sharing and isolation boundaries is key to diagnosing agent residue.

Unmerged Branches and Refs

Merged task branches. git branch --merged main --list 'hermes/*' 'worktree-*' lists merged branches. Use -d to delete while main is checked out — it refuses to delete branches that aren't fully merged. Before deleting a branch, remove its worktree first.

Squash-merged or rebased branches won't appear in this list — their changes are on main, but the branch tip commit is unreachable from main, so --merged skips them. These fall into the next category.

Unfinished branches. Use git for-each-ref --sort=committerdate --no-merged=main to sort by last commit time, oldest first, putting abandoned experiments at the top. git branch -D is a forced delete — before running it, use git log main..<branch> to confirm there's nothing worth keeping.

Refs git branch can't see. Tools can keep their own data under refs/. Use git for-each-ref --format='%(refname:rstrip=-2)' | sort | uniq -c to count by namespace. git gc keeps all objects referenced by branches, tags, reflogs, the index, and "anything else in the refs/* namespace." A namespace full of snapshot refs can pin a lot of old blobs. Before deleting refs written by a tool, check that tool's docs first — it might be its undo history. Once confirmed safe, delete with git update-ref -d <ref>.

---

git for-each-ref is a low-level Git ref traversal command that's more general than git branch and better suited for scripting. git branch only shows branches under refs/heads/, while git for-each-ref can traverse all ref namespaces, including refs/tags/, refs/remotes/, and tool-defined namespaces (like refs/hermes/, refs/codex/). Its --format argument supports placeholder syntax like %(refname:rstrip=-2) to truncate the last segment of a ref path for grouping by namespace. --sort=committerdate sorts by last commit time, and --no-merged=main filters refs not merged into main. These capabilities make git for-each-ref the core tool for discovering "hidden ref residue," especially when tools write snapshots or undo history under refs/ — it's the only thing that lists them all.

Copies: Dependencies and Ignored Files

node_modules in every worktree. New worktrees only contain tracked files, so every worktree where an agent ran install has its own dependency folder. Use git worktree list --porcelain combined with awk and du -sh to measure node_modules size across all worktrees. For worktrees you'll return to, deleting node_modules is cheap — just reinstall when you come back. For ones you don't need, remove the whole folder.

Ignored and untracked files. Agents and the people operating them leave pasted screenshots, log files, and notes in worktrees. git clean -nd shows untracked and non-ignored files; git clean -ndX shows only ignored files. -n only displays what will be deleted. Read the -X list carefully: .env and node_modules are also ignored files, and a blanket git clean -fdX will take them out too. Deleting by path is safer.

Processes and the .git Directory

Dev servers still holding ports. A dev server started in the background can outlive the agent session that started it, and the next worktree's server finds the port already taken. Use lsof -nP -iTCP -sTCP:LISTEN to list all listening TCP sockets. -iTCP -sTCP:LISTEN is the man page's own example, and -n and -P skip hostname and port name lookups.

To confirm which folder a process is running in and which worktree started it, query its working directory: lsof -a -p "$PID" -d cwd. Once you've confirmed it's your process, terminate it: kill "$PID".

A .git directory that only grows. All worktrees share one object store, and every agent's commits land in the same place. Measure with git count-objects -vH: size is space used by loose objects, size-pack is pack files, size-garbage is files that are neither. Then run git gc.

After branch deletions, gc can discard objects no longer referenced, but not immediately. By default it only prunes loose objects older than two weeks, and reflog entries for unreachable commits are kept for 30 days. The disk drop from deleting branches may not appear for weeks. To reclaim space immediately, run git reflog expire --expire-unreachable=now --all and git gc --prune=now. This discards reflog entries used to recover accidentally deleted commits, so run it after cleanup is complete, not before.

---

git gc (garbage collection) is Git's maintenance command, responsible for packing loose objects, deleting unreachable objects, and cleaning up reflogs and expired refs. Its reclamation behavior has default grace periods: gc.pruneExpire defaults to two weeks, only pruning loose objects older than that; gc.reflogExpireUnreachable defaults to 30 days, keeping reflog entries for unreachable commits for 30 days. This means that even after deleting a branch, as long as the reflog still references old commits, those objects won't be reclaimed. To free space immediately, you must explicitly run git reflog expire --expire-unreachable=now --all to clear all unreachable reflog entries, then run git gc --prune=now to force immediate cleanup. Skipping the reflog expiration step and running git gc directly usually won't achieve the expected result. Understanding these two time parameters is the only way to explain why disk space doesn't drop immediately after deleting a branch.

What Tools Can Clean Up for You

At the end of the article, the Hermes IDE author explains his own tool's cleanup capabilities, with a caveat: "Given that I'm developing Hermes, please read this section with that in mind." Hermes 2.2.9 fixes issues that accumulate after long app runs: historical snapshots of tasks run in worktrees are removed from the repo 14 days after session close; worktrees that couldn't be removed at session close are retried on next launch; worktrees users chose to keep are no longer auto-deleted; screenshots pasted a week ago, session output closed a month ago, landed task rollback data after 14 days, and worktree backups after 90 days are all cleaned up.

However, the 2.2.9 notes don't mention ports and git gc, and the author recommends still handling items 8 and 9 manually.

Claude Code runs periodic scans, removing sub-agent and background session worktrees older than the cleanupPeriodDays setting, skipping ones that still have work in progress. Codex saves snapshots before deleting managed worktrees so the conversation's work can be restored later.

These tools each manage their own, and the list the author provides covers what's left. If a developer uses multiple agents at once, each tool cleans up its own worktrees, but residue outside worktrees — ports, the shared object store, manually created branches — needs manual handling.

A principle worth remembering: run read-only commands first to see the list, confirm, then execute deletions.

One-line Summary

Parallel AI coding agents leave 9 types of disk residue that need to be inspected first and cleaned up manually.

Paragraph Summary

When multiple AI coding agents run simultaneously, they leave behind 9 types of residue: abandoned worktrees, stale locks, unmerged branches, hidden refs, duplicated node_modules, ignored files, port-holding dev servers, and a bloated .git directory. Each agent only cleans up after itself, but shared resources outside worktrees go unhandled. The article provides two commands for each residue type — inspect first, delete second: from git worktree list to git clean, from lsof to git gc. Key details include: Claude Code's claude -p --worktree doesn't auto-release worktrees, Codex keeps 15 by default, and git gc's delayed reclamation can take weeks to free space. Hermes 2.2.9 adds automatic cleanup but still doesn't cover ports and gc. The core principle is to always run read-only commands first to confirm the list, then execute deletions.