Two agents, one git index
- date
- 20260913
- what happened
- More than one AI agent works the same git working tree concurrently. While one agent, authoring as Rigger, was part-way through an unrelated commit, a second agent staged 17 files for its own change. Rigger's commit ran first and swept all 17 files into it, with no error or conflict, and the second agent's commit immediately after reported nothing added to commit.
- what it cost
- One agent's work landed, correctly, inside another agent's unrelated commit message, which would have made the history misleading if nobody had caught it. Nothing was lost, but the near-miss that followed was worse than the mix-up. The second agent nearly split the other's commit apart to recover its files, which would have rewritten someone else's history.
- what changed
- Each agent now works in its own worktree, which gives it its own index and is the actual fix. Within a shared checkout, stage and commit as one shell invocation, inspect the staged diff first, and always name explicit paths rather than staging a whole directory or everything.
- the check now
- Check the commit log before assuming your own commit failed. An unexpected author on the commit that contains your files is the tell.
Anyone running more than one AI coding agent, or one person and one agent, against the same working tree should internalise the mechanism before meeting it for real. Staging writes to a file on disk, the index inside the git directory. It is not session-scoped or process-scoped. Any commit that runs in that tree commits whatever happens to be staged at that instant, regardless of which process staged it.
The failure is unusually quiet. There is no error, no conflict, no lock contention to notice. There is a commit that contains more than its author intended, and a second commit that reports having nothing to do. Both outcomes look like ordinary git output, and the misleading part, the commit message describing only half of what the commit contains, is only visible to someone reading the diff.
The recovery rule matters as much as the prevention rule. Once another agent’s commit already holds your work, and holds it correctly, rewriting that commit to fix the attribution destroys a shared, trusted history for a cosmetic gain. In a tree where other threads have work in flight, that cost is not hypothetical. The right move is to verify the content landed intact and add a new commit that explains and cross-references it. Attribution is repairable by addition. History is not.
Source: node0 lessons v0.1, lesson 6.11. Sanitized: checklist v0.1, 20260921; repository name; voice pass 20260921. Part of oznog.com/node0.