# Git worktrees eat disk space: how to keep it under control

> Each git worktree uses disk space: a full checkout plus its own dependencies and builds. How to measure it, prune old worktrees and share the heavy parts.

Source: https://shuriken.sh/guides/git-worktree-disk-space

Each git worktree uses disk space: a full checkout plus its own dependencies and builds. How to measure it, prune old worktrees and share the heavy parts.

By Shuriken Updated 27 October 2026 5 min read

**Contents**

A git worktree shares your repository's history, but each one holds a full copy of your files, and then your build fills it with its own node_modules, target or .venv. So worktree disk space grows with every checkout you keep. Measure with du, delete finished ones with git worktree remove, and let a shared package store carry the dependencies.

Our own repository, where coding agents each work in a worktree, is the example below; after it come the commands and what to share.

## Why a git worktree uses so much disk space #

Git's own [documentation](https://git-scm.com/docs/git-worktree) says a new worktree is "linked to the current repository, sharing everything except per-worktree files such as HEAD, index, etc." .git/objects, the history, exists once. Everything else is per worktree:

- every tracked file on the worktree's branch;
- dependencies, because a fresh checkout has no node_modules (npm and Yarn's default linker install a full copy into each one);
- build output: dist, .next, Rust's target, Gradle's build, Python virtual environments;
- generated caches: test caches, coverage reports, downloaded browsers for end-to-end tests.

On 22 October 2026 our repository's tracked files came to about 320 MB, and the node_modules at its root to about 10 GB. A worktree that only checks out costs 320 MB; run npm install in it and it costs more than thirty times that.

Three days later, on 25 October 2026, git worktree list showed 12 worktrees. Here is what du -sh said about them:

| Worktrees | Each, du -sh | Of which node_modules |
| --- | --- | --- |
| 10 agent worktrees | 18 to 22 GB | 17 GB |
| 1 with no install | 655 MB | none |

Your project will land somewhere else, so measure it.

## How to see where the space went #

git worktree list prints every worktree git knows about, with its path, commit and branch. Then measure them. On macOS and Linux:

bash
du -sh "$(git rev-parse --show-toplevel)"/../*/ # sibling folders, if you keep worktrees side by side
du -sh .claude/worktrees/* # Claude Code's --worktree folders
du -sh */node_modules */target 2>/dev/null # the usual heavy subfolders

git worktree list --verbose also marks a worktree prunable when its folder is gone but git still remembers it.

## How to clean up worktrees you're done with #

- git worktree remove <path> deletes a finished worktree. Git refuses while it holds changes or untracked files, so unmerged work can't vanish by accident; --force overrides that.
- git worktree prune tidies up after folders you deleted by hand (try git worktree prune --dry-run -v first). It removes git's notes, not files, so it frees little space, but it does let you reuse the branch.
- git branch -d <branch> deletes the branch once it's merged.
- git worktree lock --reason "…" <path> protects a worktree on a removable drive from pruning while the drive is unplugged.

Claude Code's own worktrees (claude --worktree name) clean up after themselves only part of the way, per Anthropic's [worktree docs](https://code.claude.com/docs/en/worktrees). An unnamed session removes its worktree on exit if it's clean and asks if it isn't. Worktrees from -p runs stay, and subagent worktrees with changes wait for a periodic sweep that can remove them without losing work. Look in .claude/worktrees/ now and then; [Claude Code --worktree, explained](https://shuriken.sh/guides/claude-code-worktree-flag) has the exit rules in full.

The Codex app keeps its worktrees in ~/.codex/worktrees and, by default, only the 15 most recent, with a snapshot saved before each deletion ([Codex worktrees](https://shuriken.sh/guides/codex-worktrees-parallel-agents)).

In Shuriken a chat can work on its own branch in its own worktree, and Finish merges it after your checks.

[Download](https://shuriken.sh/download)

## How to share the heavy parts #

### Share dependencies through a store #

pnpm keeps every package version once, in "a content-addressable store", and fills each project's node_modules with hard links into it, "consuming no additional disk space" ([pnpm's own words](https://pnpm.io/motivation)). Each worktree still gets its own node_modules, so branches with different dependencies don't clash, but identical packages aren't stored twice. In our numbers above, that's the 17 GB of node_modules repeated in each of ten worktrees.

Hard links can't cross file systems. With the store on another drive, says pnpm's [FAQ](https://pnpm.io/faq), packages "will be directly copied". pnpm store path prints where the store is, so put worktrees on that disk; pnpm store prune clears out packages no project uses any more.

### Don't link one node_modules into every worktree #

A symlink from each worktree to the main checkout's node_modules holds up until two branches need different versions. From then on, one agent's npm install changes another agent's build. A store gets most of the saving without that shared state.

### Check out less #

git sparse-checkout set <folders> in a worktree checks out only those folders, which pays off in a large monorepo where a task touches one package. Git stores the setting per worktree, and the others keep their full checkout.

### Copy only what you need #

Claude Code's .worktreeinclude file copies gitignored files such as .env into each new worktree. Keep it to small config files, because a pattern that matches a build folder copies the whole folder into every worktree.

## How many worktrees can you afford? #

There's no general number. Take your free space (df -h .) and divide it by one worktree's real size, measured with du -sh after an install and one build. Then leave room for the build output that appears while agents work, and for your other projects. With several agents running in parallel the count climbs fast, which is why [running Claude Code agents in parallel](https://shuriken.sh/guides/run-claude-code-agents-in-parallel) puts disk next to limits and memory as the real ceilings.

## How Shuriken handles worktree disk space #

Every Shuriken chat except a project's Main chat gets its own branch in its own git worktree, so [parallel agents](https://shuriken.sh/features/parallel-agents) never touch each other's files. On a computer those worktrees live under ~/.shuriken/worktrees/<project>/ by default. Each is a full checkout and uses disk, and Shuriken sets no cap on how many chats you run, so your disk is one of the real limits. [Why every chat gets its own git worktree](https://shuriken.sh/blog/worktree-per-chat) explains why we chose that anyway.

- Finish rebases, runs your checks and squash-merges, then removes the chat's branch and its worktree. Finish via a pull request instead and the chat closes once GitHub merges it ([Finish: checks, rebase and merge in one click](https://shuriken.sh/blog/finish-one-click-merge)).
- A project's settings have a Setup for new branches section with two boxes. Setup runs your commands when a chat's branch is created and Teardown when it's removed. Put pnpm install --frozen-lockfile in Setup and every chat's dependencies come from your one pnpm store.
- The Main chat works in your own folder on your own branch, so a quick fix costs no extra checkout.

If you want worktrees per task without hand-cleaning them, [download Shuriken](https://shuriken.sh/download) and let Finish tidy up after each chat.

Share

[X](https://x.com/intent/post?url=https%3A%2F%2Fshuriken.sh%2Fguides%2Fgit-worktree-disk-space&text=Git%20worktrees%20eat%20disk%20space%3A%20how%20to%20keep%20it%20under%20control)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fshuriken.sh%2Fguides%2Fgit-worktree-disk-space)[Hacker News](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fshuriken.sh%2Fguides%2Fgit-worktree-disk-space&t=Git%20worktrees%20eat%20disk%20space%3A%20how%20to%20keep%20it%20under%20control)[Reddit](https://www.reddit.com/submit?url=https%3A%2F%2Fshuriken.sh%2Fguides%2Fgit-worktree-disk-space&title=Git%20worktrees%20eat%20disk%20space%3A%20how%20to%20keep%20it%20under%20control)[E-mail](mailto:?subject=Git%20worktrees%20eat%20disk%20space%3A%20how%20to%20keep%20it%20under%20control&body=https%3A%2F%2Fshuriken.sh%2Fguides%2Fgit-worktree-disk-space)

## Sources

- [git-worktree documentation](https://git-scm.com/docs/git-worktree) (accessed 22 October 2026)
- [git-sparse-checkout documentation](https://git-scm.com/docs/git-sparse-checkout) (accessed 22 October 2026)
- [pnpm: Motivation (content-addressable store)](https://pnpm.io/motivation) (accessed 22 October 2026)
- [pnpm FAQ: multiple drives or filesystems](https://pnpm.io/faq) (accessed 22 October 2026)
- [pnpm store](https://pnpm.io/cli/store) (accessed 22 October 2026)
- [Run parallel sessions with worktrees (Claude Code docs)](https://code.claude.com/docs/en/worktrees) (accessed 22 October 2026)

## Frequently asked questions

**Do git worktrees duplicate the repository?**

No. History and objects are shared with the main checkout. Each worktree repeats the checked-out files and whatever your build puts in its folder, node_modules or a target folder for example.

**How do I delete a git worktree properly?**

Run git worktree remove <path>. It refuses if the worktree has changes or untracked files; add --force only once you're sure. If you already deleted the folder by hand, git worktree prune cleans up what git still remembers.

**Does git worktree prune free disk space?**

Hardly. It only removes git's notes about worktrees whose folders are already gone. The space is in the folders themselves, which git worktree remove deletes.

**Can worktrees share node_modules?**

Not safely by copying or linking one folder, since branches can need different packages. A package manager with a shared store, such as pnpm, gets most of the saving: each worktree has its own node_modules, made of links into one store.

Parallel agents

Agents side by side, each on its own branch if you want.

A new chat gets its own branch and worktree unless you pick the project folder, so agents don't step on each other. Finish runs your checks and merges each one back.

[Download](https://shuriken.sh/download)

[Other platforms](https://shuriken.sh/download#main)

## Keep reading

- [Claude Code on a large codebase: what actually works: Guide 27 Oct 2026 5 min read Claude Code large codebase tips that work: start in the package, a CLAUDE.md per area, block generated code, subagents for reading, tests as the contract.](https://shuriken.sh/guides/claude-code-large-codebase)
- [Claude Code with multiple repos: --add-dir and /add-dir: Guide 27 Oct 2026 3 min read One Claude Code session over multiple repositories: --add-dir gives Claude a second repo's files, not its CLAUDE.md, hooks or MCP servers. The setup.](https://shuriken.sh/guides/claude-code-multiple-repositories)
- [Run multiple Claude Code sessions in tmux: Guide 27 Oct 2026 3 min read Run several Claude Code sessions side by side in tmux, each in its own git worktree, and keep them running after you close the terminal. Commands included.](https://shuriken.sh/guides/claude-code-tmux-multiple-sessions)
- [Resolving merge conflicts with Claude Code: Guide 27 Oct 2026 6 min read Parallel Claude Code agents still hit merge conflicts. Merge one branch, rebase the next onto it, give Claude both intents and test before you continue.](https://shuriken.sh/guides/resolve-merge-conflicts-with-claude-code)

## Free tools

- [Claude limit reset tracker](https://shuriken.sh/tools/limit-resets/claude)
- [Codex limit reset tracker](https://shuriken.sh/tools/limit-resets/codex)