AGENTS INPARALLEL

refs/stash starts with refs/, so the rule above puts it on the shared side — one stash list for the whole repository, not one per worktree. Verified: git stash in wt-retry, then git stash list in wt-parse shows it, and git stash pop there would apply another agent’s work into your tree. Two agents that both stash are writing to the same stack. The exceptions to the rule are refs/bisect, refs/worktree and refs/rewritten, which are per-worktree despite the prefix. None of them come up here; the stash does.

Git shares its own data; it shares nothing else. Each worktree needs its own node_modules, its own build output, and its own .env — because those live in the working tree, and each worktree has a separate one. Untracked files do not travel between them either, which is usually what you want and occasionally a surprise.

Every guarantee on this page is a property of one repository, and a colleague is a different repository. The branch lock is the one that matters. It stops two of your worktrees from checking out one branch — but two clones can both sit on feature at the same time with no complaint from either, which is the ordinary state of any team. Verified: two clones of one repository, both switched to the same branch, no refusal. So the collision the lock makes impossible for your agents is merely normal between people, and what makes it survivable is that their commits arrive through a remote, where the push either fast-forwards or is refused. The same applies to the shared stash and the instant visibility of commits: both are consequences of one object database. Two people have two, so a colleague’s commit is invisible until somebody pushes and somebody fetches. When you scale from three agents to three people, the file-intersection screen still works — but it has to run on origin/* refs, after a fetch, rather than on local branches.