Before cleaning up worktrees, check what is still there.
When several coding agents are working at once, the list of worktrees can get hard to follow. A session ends, a branch looks old, and a folder starts to look disposable. The thing worth checking is what that folder still contains.
I build Holt, a local tool for this problem. You can do useful checks with Git alone, too. Here is where I would start.
Start with the list, then inspect each checkout.
git worktree list --porcelain git -C /path/to/worktree status --short --untracked-files=all git -C /path/to/worktree ls-files --others --ignored --exclude-standard
Replace /path/to/worktree with a path from the first command. Repeat the checks for the worktrees you are reviewing, including your main checkout. The last command lists ignored files separately so they are not silently left out of your review.
A clean git status in your main checkout says something about that checkout. Another worktree has its own index and working files. It can still contain an untracked migration or a local edit that has not reached a commit. See Git's status documentation and worktree documentation.
Remove and prune do different jobs.
git worktree remove removes a checkout. Git refuses an unclean worktree unless you force it. git worktree prune removes stale administrative records for worktrees that are already missing. Prune does not inspect and tidy every existing worktree for you. Those behaviors are documented in Git's worktree manual.
If Git refuses removal, inspect the files it is protecting. Forcing the command should not be the automatic next step. Also check whether local commits are preserved in a branch or other durable reference before making a separate branch-deletion decision.
Look at more than the branch name.
- Modified and staged files: does someone still need to review or save them?
- Untracked files: is this a new source file, migration, note, or other work that Git has not committed?
- Ignored files: are they replaceable dependencies, or useful local data? The directory name alone does not answer that.
- Local commits: is the work preserved in the intended branch, and has it actually been integrated where you expect?
- Active sessions: is an agent still writing here? Finish or pause that work before treating the checkout as settled.
Where Holt helps
Holt brings the linked worktrees into one local view and looks for work with no durable copy elsewhere. The first check on the Holt homepage runs in strict read-only mode. It changes no repository files, hooks, or locks and does not upload your source.
That quick check deliberately skips symbol analysis, and committed comparisons can be marked approximate. It helps you find what needs attention. It is not a deletion verdict or an off-machine backup. Holt's protection, recovery, and quarantine commands are separate workflows described in the repository.
I'd like to know how this goes in your setup.
I'm a solo developer building Holt as a product of Contrare Research. If you already have several worktrees, try the first check and tell me whether it shows you anything useful. If it is slow, confusing, or unnecessary, I want to hear that too.
Holt's single-repository core is free and source-available under FSL-1.1-MIT for its defined permitted purposes. It is not currently OSI open source.