
git commit ships the whole index, not the paths you staged
Vodou CTO Chad Priest documents two incidents in which agent sessions staged a few paths and shipped dozens of files: a bare git commit snapshots the whole worktree index, which every session shares.
Vodou CTO Chad Priest described on dev.to two incidents in which agent sessions sharing one checkout committed each other's changes.
Eight paths staged, twenty files changed
On 9 September 2026 an agent session in his repository staged eight paths, all in the gateway directory MCP-servers/Vodou-Console/, and ran git commit. Git answered "20 files changed". The other twelve belonged to a second session in the same checkout, which already had thirteen files staged, including a 466-line test fixture and much of the engine.
It had happened before. On 28 July 2026 a session staged three paths for a lease feature, and a parallel session ran git add between that add and the commit: it swept in a 185-line hunk from the engine's daemon, four files under MCP-servers/brain/ and scripts/build-server-bundle.sh.
Why staging explicit paths does not help
Priest's rule at the time was to stage explicit paths and never run git add -A. He says he trusted it for most of a month and was wrong: the rule fixes one actor's selection, not what the commit reads.
A bare git commit does not commit what you added, it commits the index, and there is one index per worktree, at .git/index. Every session in that worktree reads and writes the same file, so a single git add is one write into a buffer other processes are writing to as well. In July a peer wrote during his window; in September the peer's work was already staged before his session started.
Two fixes, and the limits of isolation
Git aside, the pattern is any shared, mutable staging area whose publish step snapshots everything instead of the worker's declared inputs. Priest sees it in parallel coding agents sharing one worktree, among other places.
His first fix is git commit --only with a path list, which commits the working-tree version of just those paths. That fails when two agents edited the same file, so he uses a private index instead: GIT_INDEX_FILE=/tmp/agent-a.index, git read-tree HEAD, git apply --cached. A worktree per agent is the standard answer, but it did not fit a repository where agents all edit one running system and must see each other's changes live.
After a private-index commit, git status goes stale and reports deletions of files HEAD already has, so he verifies with git cat-file -e HEAD:path. His rule for any system with more than one writer: look at what the publish step reads, not at what you added.
SiTech — AI-powered web development
We build fast, modern websites and bring AI into real business workflows. Have a project or a question? We'd love to help.