You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Each dev worktree costs ~160 MB and ~372k files; deleting one takes minutes #26926
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
Build, CI, or release tooling
Steps to reproduce
On macOS (APFS), check out this repo into many git worktrees, as agent threads do (one worktree per thread).
Run the normal worktree setup (vp i) in each, with the default per-project pnpm virtual store.
Measure the physical disk use per worktree on an isolated volume, then rm -rf node_modules.
Expected behavior
Additional dev worktrees should cost little disk and be cheap to delete, since the package files are already in pnpm's content-addressed store.
Actual behavior
Measured on macOS (APFS), warm store, one worktree each, on an isolated APFS volume so other writes couldn't skew it:
per worktree
per-project virtual store (default)
global virtual store
physical disk
~160 MB
~5.5 MB
entries under node_modules
~372k
~2.4k
install
119–137 s
~2.6 s
rm -rf node_modules
143–153 s
~0.14 s
The global store itself is a one-time ~7.6 GB. du reports ~6–7 GB per per-project worktree because APFS clones are counted per copy. The physical cost is the ~160 MB above, plus ~372k files of metadata that every delete has to walk.
macOS 27, APFS, pnpm 11.28.6 for the comparison. With ~100 agent worktrees on one machine, that's ~15 GB of disk and minutes of delete I/O per cleanup, and the disk fills during multi-agent work.
Logs or stack traces
No response
Screenshots, recordings, or supporting files
#22765 tried an opt-in global virtual store and was closed because pnpm 12 took most of the install-speed win; disk and delete time weren't part of that decision. Proposal and discussion: #26925
Workaround
Our fork runs pnpm's virtualStoreType: global unconditionally, CI included, so type resolution can't differ from CI. Vite, Metro and desktop packaging follow the store links through one shared helper. Happy to send a focused PR if maintainers want it.
Thanks for writing this up. It asks for new behaviour rather than reporting a defect, so it does not belong in the bug tracker and I'm closing it as not planned here. Feature ideas are discussed in Discussions: please post it there.
Activity
juliusmarminge commentedon Nov 12, 2026
Thanks for writing this up. It asks for new behaviour rather than reporting a defect, so it does not belong in the bug tracker and I'm closing it as not planned here. Feature ideas are discussed in Discussions: please post it there.