One Checkout, N Sessions, One HEAD

The multi-agent rules I had in May were about keeping different agents out of each other's territory: Claude stays out of Codex's worktrees and vice versa. What they did not cover was several sessions of the same agent attaching to the one canonical checkout at the workspace root. Each session would `git checkout` its own branch there, under the others. A write issued by session A while the root sat on session B's branch lands in B's working tree. The path is correct, the repo is correct, and the result is silent cross-contamination that no ownership rule can see.

The fix is a lock, with three design choices that made it workable rather than annoying. First, where it lives: inside the shared git directory, so it is identical across every linked worktree, invisible to `git status`, and never tracked. It records which session holds the root, on which branch, and when it last wrote.

Second, staleness instead of liveness. A standalone check has no reliable way to ask whether the owning process is still alive, but it does see every write. So each governed write refreshes the lock, and a lock with no write inside twenty minutes is treated as abandoned and freely taken over. A crashed session can never deadlock the root, and an active one keeps its claim just by working.

Third, fail-open. If the payload is malformed or the session cannot be identified, the write is allowed. That sounds backwards for a safety mechanism, but this lock is a net under a rare structural hazard, not the sole control; failing closed on bad input would brick every write over a parsing bug, and a guard that hurts you daily gets removed within a week.

The part I find most satisfying: the lock itself was built in an isolated worktree rather than on the contended root it protects. If the thesis is that shared roots are dangerous, the construction of the fix should not depend on one being safe.