The breakthrough is boring directory ergonomics.
Git already supports multiple linked working trees. Each gets its own working files plus per-worktree state such as HEAD and the index, while sharing the repository’s broader administrative data.[2] That is the right primitive for parallel coding jobs: separate checkout surfaces without cloning the whole repository for every task.
The primitive is powerful and the factory UX is fussy. Worktrunk’s core pitch is to address a worktree by branch name, compute its path from a template, and compress create, switch, list, merge, and remove workflows into a small command set. Its README shows wt switch -c -x claude feat creating a branch/worktree and starting a command in it, while wt list adds working-state context beyond paths.[1]
Parallelism becomes usable when isolation has an address and a cleanup ritual.
The worktree is a bay, not a force field.
Git’s documentation is explicit about what is separate and what is shared. A linked worktree has per-worktree files, but it remains attached to the same repository. Administrative files for missing worktrees can be pruned; worktrees on removable or intermittently mounted storage can be locked to protect that state.[2]
That boundary matters for agents. Separate checkouts stop two jobs from writing the same working file. They do not automatically allocate separate ports, databases, cloud sandboxes, credentials, caches, or rate limits. Worktrunk offers hooks, branch-scoped variables, hashed dev-server ports, and build-cache sharing patterns; those are useful routing mechanisms, not automatic safety guarantees.[1]
Warm starts are where the tool earns its lift.
Worktrunk documents post-start hooks for setup, per-worktree dev-server ports, and copy-on-write sharing of ignored build artifacts on supported filesystems. The attraction is obvious: five isolated jobs are less useful if each one spends the first ten minutes rebuilding the same world.
But speed needs labels. A copied dependency cache is not the same thing as a clean install. A hashed port avoids one collision class, not database or queue collisions. A hook is executable policy. Print what ran, where it ran, and which resources were shared. Invisible convenience is still invisible authority.
Editors are feeling the same pressure.
VS Code 1.137 lets a quick chat attach to a workspace and offers an isolated-worktree option during that transition. Zed 1.19.2 includes fixes for linked-worktree names and creation paths in bare repositories, alongside better behavior around project diffs and Git state.[3][4] Different products, same signal: worktrees have moved from obscure Git furniture into front-line agent cockpit plumbing.
That is capability evidence, not proof that every team should run a swarm. Start with two bays and one merge queue. If review time, environment collisions, or cleanup debt scale faster than completed work, the answer is not a sixth terminal pane.
Run five visible stages.
- Create: bind task, owner, base revision, branch, path, and write scope before launch.
- Warm: run declared setup hooks; allocate ports and external resources; record what is copied or shared.
- Work: keep each job in its bay; surface dirty state, drift from base, and resource collisions.
- Land: stop services, update from the chosen base, run relevant checks, review the diff, and use one explicit merge authority.
- Scrub: remove the worktree and branch only after proof survives elsewhere; prune intentionally, never as mystery housekeeping.