Single-Writer Machinery for Multi-Session Agentic Coding

If you run two AI coding sessions against the same repository at the same time, the standard advice is: do not do that. Use worktrees. Use sandboxes. Use containers. Give each session its own filesystem. The conflict surface disappears because the shared surface disappears.

This works. It is not always available.

When an interactive session and an autonomous background run share a live codebase because they share the codebase by design, isolation is not the answer. The interactive session owns memory, decisions, and runtime config. The autonomous run owns its own output files. Both write to the same repository. Both must not corrupt each other.

The single-writer machinery is the pattern for making that safe. It does not prevent two sessions from running. It prevents them from writing to each other’s paths, from sweeping each other’s staged changes into unrelated commits, from each believing it has exclusive access when it does not.

The machinery is four components. This write-up names them, describes how they compose, surveys the prior-art landscape, and discloses where the novelty claim is uncertain.

i.The Problem Isolation Solves and the Problem It Does Not

Worktrees (Claude Code’s published recommendation), per-task sandboxes (OpenAI Codex), and per-session containers (OpenHands) all solve the same problem: two sessions editing the same file at the same time. Their solution is to ensure that no two sessions ever see the same file. Each session gets its own copy of the repository.

This eliminates write conflicts. It also means that session A cannot see what session B is doing, cannot claim ownership of a path it is not using, and cannot prevent session B from writing to files that session A considers its own operational territory.

For fully independent tasks that do not share context or outputs, isolation is exactly right. For a setup where an interactive session and an autonomous run share one repository because they both read from the same decision log, the same memory files, and the same task registry, isolation creates new problems. The two sessions need to coordinate, not separate.

The coordination problem is what the single-writer machinery solves.

ii.The Four Components

Component one: the live session registry. Every session that opens the repository registers itself with a process ID and a heartbeat timestamp. The registry is a file in the repository (outside git tracking, in a gitignored runtime directory). Any session can read the registry to know what else is running. When a session exits, its registration expires by staleness.

The registry answers the question: is anyone else here? Before an autonomous run starts, it reads the registry. If an interactive session is registered and alive, the run knows it has company. The run does not stop. It proceeds with the claim machinery active.

Component two: per-session file path claims. When a session writes a file, it claims that path. The claim is a record: session ID, path, timestamp. Claims accumulate in a runtime claims file (also gitignored). A claim does not prevent other sessions from reading the file. It prevents other sessions from writing it.

Claims are auto-acquired on write. The session does not need to pre-declare everything it might touch. Writing to a path is the claim act.

Component three: hard-deny on write against a live run’s claimed paths. When an autonomous run has active claims, any write attempt against those paths from a different session is denied. Not warned. Denied. The deny is logged with the claiming session ID and the attempted writer’s session ID.

This is the enforcement layer. A session that tries to write to a path owned by a live run gets a hard stop. The session continues; only the specific write is blocked. The interactive session can still read the run’s output files, update files in its own territory, and continue working. It simply cannot write to paths the run owns.

Component four: pathspec-limited commit enforcement. Git has one staging index per working tree. When two sessions both stage files and one calls git commit, the commit takes everything in the index, including files staged by the other session. This is not a bug. It is how git works. And it means that disciplined per-session staging is not enough: if the commit boundary is not also constrained, the commit sweeps foreign staged changes.

The fix is pathspec-limited commits: git commit -- <paths> where the paths are the committing session’s own claimed files. A hook blocks any plain git commit without pathspec under multi-session conditions. The interactive session cannot accidentally commit the autonomous run’s staged output, and the run cannot accidentally commit the interactive session’s staged edits.

iii.How the Components Compose

The four components are individually simple. Their composition is the pattern.

The registry tells sessions they have company. Claims tell the enforcement layer who owns what. The deny gate enforces claims at write time. The commit hook enforces session boundaries at commit time.

A session that tries to write to a claimed path gets a hard stop immediately, before the write lands on disk. A session that tries to sweep a plain commit gets a hard stop at commit time, before any foreign staged changes enter the commit object. Both failure directions are caught at the earliest possible point.

The machinery has one important property: it failed safely on its first live contention. The guard correctly blocked its own launcher’s claim attempt, because the launcher’s claim registration had a timing gap relative to the deny check. The guard caught this and logged it. The claim timing was adjusted. The failure direction was the safe one: the guard blocked too eagerly rather than too leniently.

A guard that fails safe on its first real contention has demonstrated the thing that matters: the denial path works end-to-end under real conditions, not just in test harnesses with injected signals.

iv.Prior Art and Novelty Posture

The prior-art sweep for this pattern (conducted 2026-06-06, archived at queue/2026-06-06-pattern-papers/prior-art-sweep.md) surveyed Claude Code worktrees documentation, OpenAI Codex, OpenHands, CC agent teams documentation, and practitioner community sources.

The verdict: NOVEL-AS-COMPOSED, confidence MEDIUM-HIGH.

The confidence is higher than for the demo-gate pattern because the published state of the art is structurally the alternative approach. Worktrees give each session its own filesystem. Sandboxes and containers do the same. The published literature treats isolation as the solution to the shared-repo problem, which means the shared-repo-coordination problem is unaddressed in the published literature.

To be precise about the novelty claim: “The published approach to parallel AI coding session safety is filesystem isolation: worktrees (Claude Code), per-task sandboxes (OpenAI Codex), or per-session containers (OpenHands). These prevent conflict by giving each session its own copy of the repository. The single-writer pattern addresses a different problem: multiple sessions sharing one repository by design (for example, an interactive session and an autonomous run on the same codebase). The coordination machinery, a live session registry with PID and heartbeat, per-session file path claims, hard-deny on write against claimed paths, and pathspec-limited commits, is the mechanism that makes shared-repo multi-session safe. To our knowledge this specific composition has not been published.”

This is a novel-as-composed claim in a space where the published solutions are structurally different from the proposed pattern. The confidence is MEDIUM-HIGH because the absence of published coordination machinery is itself strong evidence: the field chose isolation as the answer and did not need to publish coordination.

v.Disclosed Gaps

First: Devin’s parallel-session documentation was not accessible at time of sweep (URLs returned 404). Commercial AI coding assistants that support parallel sessions may have developed equivalent coordination machinery without publishing it. The prior-art gap is bounded to published and accessible sources.

Second: practitioner communities (enterprise AI teams, platform engineers running multi-agent systems) may have implemented equivalent patterns as internal infrastructure without publishing them. Community forums and practitioner posts were auth-walled or inaccessible at time of sweep. Internal organizational practice is not searchable from primary sources.

Third: the registry and claims components resemble distributed systems coordination primitives (leases, tokens, lock files). The composition specifically for multi-session AI coding in a shared git repository is the novel element, not the individual components. If a reviewer frames the components as prior art, the response is that the framing misses the compositional claim: the combination, applied to this specific problem, is what has not been published.

Fourth: the pathspec-limited commit enforcement interacts with git’s shared index in ways that are well-documented in git internals but not documented as a safety measure for multi-agent systems. The connection from shared-index hazard to pathspec-limited commit as a multi-session safety mechanism appears to be original to this implementation.

vi.When to Apply This Pattern

The single-writer machinery is appropriate when two or more sessions share a repository by design and the sessions have different ownership domains (interactive session owns runtime and config; autonomous run owns its output files) that must stay clean across concurrent execution.

It is not appropriate as a replacement for isolation when isolation is available. If sessions can run in separate worktrees without operational friction, worktrees are simpler and sufficient.

The decision condition: does the design require sessions to share the same working tree? If the interactive session and the autonomous run need to read each other’s outputs in real time, if they share a task registry or decision log that is not practical to replicate, if the architecture assumes one canonical working directory, then isolation is not available and the coordination machinery is needed.

In that configuration, the single-writer machinery is the mechanism that makes shared-repo multi-session operation safe enough to run in production. The guard’s first live catch proved the denial path works. That is the evidence threshold for production deployment.