Running out of disk space with Git worktrees

Running many coding agents at once is a big productivity booster. One might be fixing a bug while another builds a feature, and a third could be trying a new experimental approach. With Git worktrees, each one can edit its own copy of the code.

But then next thing you know, an install fails because your disk is full. Or your laptop slows to a halt because multiple agents started running your full test suite.

Worktrees make it cheap to start another task, but running a real development environment for every task can be much more expensive. Dependencies, build caches, databases, and browser tests all need somewhere to go, and on a local setup they compete for the same disk, memory, and CPU.

If you've been working like this, here's how to get your laptop back into shape: see what's taking up disk space, find what you can clean up, and decide when it makes sense to move work off your laptop.

What takes up disk space in a Git worktree?

A worktree gives you another working directory for the same repository. Git shares the repository's objects and history, so adding five worktrees doesn't give you five complete copies of the Git database. Each checkout does have its own working files. Git's worktree documentation explains the distinction.

The less obvious cost comes after checkout, when an agent prepares the app:

• Installed dependencies. A JavaScript project may need node_modules in each checkout; a Python project may have a separate virtual environment.
• Build output and caches. Next.js writes its build cache to .next/cache. Rust's Cargo puts build artifacts and intermediate output under target by default. Building in several checkouts can leave several sets of these files.
• Test artifacts. Depending on your test configuration, browser recordings, screenshots, traces, and coverage reports can remain after a run.
• Local services. Container images, build caches, and database volumes can consume space outside the worktree altogether.

How much gets duplicated depends on your tools. For example, pnpm links package files from a shared store, so several node_modules directories don't necessarily mean several physical copies of every dependency. Multiplying one directory's reported size by your worktree count won't reliably tell you how much space you'll recover.

Even with dependency sharing, each task can produce its own build output and test data. A checkout that was small when you created it may look very different after a few days of work.

Find the space before deleting anything

Start in your repository. On macOS or Linux, these commands show the filesystem's available space and the worktrees Git knows about:

df -h .
git worktree list

Pick a worktree from the list and check its size, replacing the example path with the real one:

du -sh "/path/to/worktree"

Inspect the largest checkouts for dependency folders, build output, and test artifacts. Include hidden directories such as .next and .venv; a file browser that hides dotfiles can make a checkout look much smaller than it is. Treat directory sizes as clues, especially if your package manager shares files between installations.

If you use Docker, also run:

docker system df -v

Docker's disk usage command reports images, containers, local volumes, and build cache. It only inspects them. Removing a worktree won't remove its Docker volumes: those have a lifecycle separate from the checkout and containers. Check what data a volume holds before treating it as disposable.

For a finished worktree, save or push the work you want to keep. Review its status, including untracked files, and separately check ignored files such as .env or local data. Then remove that specific checkout:

git worktree remove "/path/to/finished-worktree"

Git normally refuses to remove a worktree with tracked changes or untracked files. Don't assume that protects ignored files too. Avoid forcing removal just to get past a warning.

Also, git worktree prune only clears stale administrative records for worktrees that are already missing. It won't delete an existing checkout or reclaim its dependencies.

Free disk space doesn't fix memory and CPU pressure

An idle worktree is a directory. It doesn't consume RAM or CPU just by being there. The processes you start in it do.

An agent testing a change may run your dev server, a type checker, a database, and a browser. Start the same stack in four worktrees and all four still draw from one computer's resources, alongside your editor, video calls, and browser tabs.

On a Mac, look at Memory Pressure and Swap Used in Activity Monitor. Apple's memory usage guide explains that memory pressure considers more than free RAM, and that swap uses space on the startup disk. That means memory pressure can add disk activity just when the disk is already short on space.

Check the CPU view while the builds are running, too. If CPU usage stays high when several tasks run together, try reducing their concurrency and compare how long they take. Freeing disk space won't give those processes more CPU time.

Tests can multiply the load further. Playwright, for example, runs tests in worker processes, each with its own browser. Two agents starting a test suite can each launch several workers. Reducing the worker count can help, although each suite may then take longer to finish.

Docker adds another budget to check. Docker Desktop has CPU, memory, and disk limits for its Linux VM on supported platforms. A containerized app can reach those limits while the host still has capacity. Raising a limit may help that app, but every container still needs resources from the same host.

When cleanup becomes part of every task

If you've accumulated months of abandoned checkouts, removing them may solve the disk problem for a long time. Shared dependency storage, fewer test workers, and stopping dev servers you aren't using are sensible improvements to a local workflow.

The awkward case is when you need all those environments. You want to leave a bug reproduction intact while an agent tries a fix, keep a feature running for review, and start another task before either is finished. Deleting an old cache helps today, but the next build will create it again.

At that point, you start making decisions around the computer: wait for this build, shut down that app, or clear enough space before starting another agent. Parallel work becomes less useful when you're regularly deciding which part of it the laptop can handle.

A bigger computer gives you more room. If you're considering that route, we also compare Mac minis, shared servers, and laptop pools with boxes.dev.

Another way: give each task its own cloud devbox

It's worth taking a step back and asking: is there a better way to do all this? Your agent's inference runs in the cloud. Why do Claude Code and Codex need to run on your laptop?

They don't.

Your laptop has your full development environment, and iterating locally gives a tight developer feedback loop. But it's possible to keep both of those while moving your agent -- and all the system resources it needs -- to the cloud.

With Boxes.dev, each task gets its own cloud devbox with your development environment already set up. The agent can build and test your app there, without needing another worktree on your laptop.

All those dependencies, build caches, and test artifacts will live on the devboxes. You can leave a bug reproduction intact or keep a feature around for review without worrying about how much space it's taking up on your laptop. When you start the next task, it will get its own disk space, so you won't have to delete an unfinished task's environment to make room for it.

Builds and tests will use each devbox's CPU and memory, too. If several agents start running tests at once, those tests will run on separate devboxes instead of competing with your browser and video calls for your laptop's resources. Each devbox still has resource limits, but you won't have to fit all of their work into one computer.

You can still open the app the agent is running, test it in your browser, review the code, and ask for changes from your laptop. The agent will have a full development environment to work in, and you'll keep that tight feedback loop without running all the builds, databases, and tests locally. You can also close your laptop and let the agents keep working.

To try it, set up a project and give two agents independent tasks. Let them both run the app and test their changes, then review each when you're ready. You won't need to clear space or shut down one task to make room for the other.

Keep exploring with why we built boxes.dev, or see how teams can share a development environment. For setup details and the day-to-day workflow, read how boxes.dev works. Then sign up and try it with your own project.