Worktree disk bloat is a package-management problem before it is a Git cleanup problem.

Raed Siddiqui · Contrare Research · September 8, 2026

Coding agents often install dependencies to run a test, build a feature, or reproduce a bug. With several worktrees, those installations can make disk use grow quickly. That is real friction, but it does not make the source checkout disposable.

I built Holt after losing original work across agent workspaces. This guide separates two decisions that should stay separate: whether a worktree still holds source work, and where recreatable package data should live.

Ask the source question first.

Before reclaiming space from a worktree, check whether an agent is still using it and whether it contains local work. A directory called node_modules is a useful clue, not a proof that everything beside it can go.

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

Use a path from the first command and review the output for every checkout you intend to change. The final command is important because ignored files do not appear in the ordinary short status output. A clean main checkout does not tell you whether another worktree contains a local fix, migration, note, or generated artifact that has never reached a commit.

If the source needs preserving, stop there. Capture, commit, or otherwise settle it before making a disk decision. Git's worktree manual explains why remove and prune are different operations.

Then distinguish the local install from the shared package store.

A dependency folder inside a worktree and a package manager's cache or shared store serve different jobs. Removing a worktree-local installation can change what an active agent or test runner sees. Reclaiming unreferenced packages from a shared store can help many worktrees at once.

• npm: npm cache documentation describes npm cache verify as an integrity check that also garbage-collects unneeded cache data. It is a cache operation, not a way to decide whether the worktree's source is safe to remove.
• pnpm: its store documentation says pnpm store prune removes packages unreferenced by every project using that store. pnpm can download them again if a later install needs them.
• Yarn: cache layout depends on the Yarn version and project configuration. The current Yarn CLI reference lists yarn cache clean as a cache operation. Check whether your project deliberately keeps .yarn/cache under version control before changing it.

Use the package manager recorded by the repository's lockfile and configuration. Do not mix package managers just to reclaim space, and do not assume a build cache is interchangeable with a package store.

Where Holt helps, and where it stops.

Holt includes ignored paths in destructive analysis and can show when a worktree has content that needs review. Unresolved ignored bytes keep that worktree out of the disposable set. Holt does not deduplicate dependencies or claim semantic understanding of every ignored file.

That boundary is intentional. Holt can help you establish that a source checkout is settled. Your package manager is the right tool to reclaim its own caches or unreferenced store entries. The first check on the Holt homepage is strict and read-only, so it is a safe way to understand the worktree side before you choose a package-manager action.

Want to see that boundary before pointing a new tool at your own repository? The disposable first-look fixture creates one modified file, one untracked note, and one ignored file beside an empty sibling worktree, then runs the same check without moving or deleting anything.

A simple order of operations.

1. Pause or finish agents using the worktree you are reviewing.
2. Inspect modified, untracked, and ignored source state.
3. Identify the repository's package manager from its lockfile and configuration.
4. Use that package manager's documented cache or store maintenance for rebuildable package data.
5. Only remove a worktree after its source state is settled and Git agrees it is clean.

I'd like the awkward cases.

If repeated agent installs are making your worktree workflow painful, I would like to understand the part that is actually hard: the package manager, generated output, native builds, a lockfile arrangement, or knowing which agent is still using the checkout. I am building Holt solo at Contrare Research, and criticism is useful.

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.