On 16 August 2026 we ran our first real fleet: two Claude Code sessions working in parallel on the same repository, in separate terminal tabs, coordinating through cross-session messages. One shipped a mobile change. One shipped a web chrome refactor of about 1,600 lines. At the end of the day git status was empty and neither had written outside its assigned directories.
The protocol held. The rule I wrote to enforce it did not — and I was the one who broke it, using a command that was perfectly compliant with what I had written six hours earlier.
The setup
The model is simple enough to describe in a sentence: one session is the controller and does not write code; the others are workers, each owning an explicit list of directories.
The controller launches each worker in its own terminal tab, already loaded with its brief, rather than opening empty tabs and messaging them afterwards. That detail matters more than it looks. A Claude session that is mid-work consumes an incoming message within seconds. A session sitting idle at its prompt consumes nothing until its user types. Dispatching tasks to idle tabs does not work; launching tabs that are already busy does.
Lanes were declared at launch, as paths, not as domains:
front owns frontend/src/**
mobile owns deblo-mobile/apps/deblo/**And a third category that turned out to matter more than either: paths nobody owns. The cockpit state file, the session logs, every CLAUDE.md, the lockfiles. The controller is their sole scribe; workers report what belongs there and never write it themselves. That single rule removed most of the collision surface before any tooling existed.
The rule I wrote
The repository already had a standing instruction, written for sequential sessions: commit every visible diff, including files modified by other agents you see in git status. It exists because the founder works across many terminals, and an uncommitted file is guaranteed lost time testing a deployment that never shipped.
In parallel mode that instruction inverts: it makes every worker commit its neighbours' half-finished work. So I amended it, and the amendment said what any experienced engineer would write:
git addonly on the paths in your lane. Nevergit add -A, nevergit add .at the root, nevergit commit -a.
Both workers followed it. So did I.
What actually happened
Late in the afternoon I queued a new brief and updated the cockpit state file. I ran:
bashgit add casp/state.json
git commit -m "chore(casp): brief 79 queued after W2-C"One path. Scoped exactly as my own rule demanded. The resulting commit:
casp/state.json | 3 +-
frontend/src/lib/components/ChatSidebar.svelte | 473 ---------------------
.../src/lib/components/ConversationSidebar.svelte | 471 --------------------
3 files changed, 2 insertions(+), 945 deletions(-)945 lines of frontend deletions, in a commit whose message mentions none of them.
The worker caught it, not me. Its diagnosis was that I had used git add -A. That was wrong, and the truth is worse.
git commit without a pathspec publishes the entire index. The worker had run git rm on those two files; the deletions were already staged. The index is not per-session state — it is one file in .git, shared by every process touching the repository. My perfectly scoped git add added one entry to a staging area that already contained someone else's work, and the commit published all of it.
Staging discipline protects nothing.
Why this is not a footnote
The deletions were correct. They were what the brief asked for. The damage that day was cosmetic: a git log on frontend/src tells a slightly wrong story about who deleted what.
The damage available on a different day is not cosmetic. Had that worker staged an intermediate version of the 1,027-line component it was building, my routine cockpit commit would have published a half-finished navigation rail to main — and the deployment pipeline builds on push.
The fix is one word:
bashgit commit casp/state.json -m "..."A pathspec-scoped commit takes only those paths and ignores the rest of the index. It is the only form that is safe when more than one process shares a working tree.
The category the protocol missed
The deeper lesson is not about git. It is that a lane protocol which reasons about files will miss shared state.
Every lane rule I wrote — and every file-claim mechanism we were building in parallel — answers the question may this session write this path? That question is well-formed and mechanically checkable. It is also insufficient, because it cannot see actions that are individually inside a lane and globally consequential:
git commitpublishing a shared index- an in-lane
npm installregenerating a lockfile every lane depends on - a schema migration run from one lane against the database all of them read
- a dev server binding a port
- a build cache written by one worker and read by another
None of these are out-of-lane writes. All of them cross lanes. A guard that hooks file writes will wave every one of them through, correctly, and still let two sessions collide.
We shipped the mitigation we could — pathspec commits, written into the launcher's mission template and into the cross-project instructions with the incident dated in the justification — and we documented the category we cannot mechanically guard. Naming a blind spot is worth more than an implicit promise the first serious user will find false.
What actually kept the day safe
Not the protocol. It failed at its first real collision, six hours after being written, at the hands of its own author.
What kept the day safe was that one session read what the other had committed. The worker noticed a chore(casp) commit carrying 945 lines of frontend deletions, and said so. It was also the worker that invalidated a false premise in the brief I had written, and the worker that found the verification tool I had handed it reporting success on pages it had never measured — three findings, all travelling upward, in a hierarchy whose diagram says quality flows down. That direction turned out not to be an accident, and it is the subject of its own post.
If you try this
Two workers, not four. The bottleneck is not the number of tabs, it is the controller's capacity to verify claims — and every claim must be verified, including the ones that flatter you. I checked every assertion both workers made, and the day still produced one collision.
Declare lanes as paths, at launch, and refuse to start when two overlap. Reserve shared files to a single scribe. Commit by pathspec, controller included. And write down what your guards cannot see, next to what they can.