Answers

How do I stop AI coding agent sessions from colliding with each other?

Stop coding agent sessions from colliding by giving each one an isolated git worktree and its own branch, allowing at most one live session per worktree, never letting an agent work directly on the main branch, and requiring every session to end with its work either merged or pushed to a branch. Context continuity is the second half — a session's memory ends when it does, so anything the next session needs must live in a file, not in the conversation.

Session management is the least glamorous part of running AI coding agents and the one that causes the most actual damage. It is also almost entirely solvable with rules rather than software.

The collision problem

Two agents editing the same checkout will destroy each other’s work. This is not a subtle race condition — it is two processes writing the same files — but it stays hidden longer than you would expect, because both sessions report success. One session’s uncommitted changes get swept into another’s commit, or reverted by a checkout, and nothing errors.

The fix is physical isolation, not coordination:

• One git worktree per concurrent session. Each gets its own directory and its own branch. Two agents cannot conflict over files they cannot both see.
• At most one live session per worktree. Two agents in one directory is the original problem with more steps.
• Never work directly on the main branch. It is the base every other worktree depends on, and an agent committing to it mid-flight changes the ground under every session at once.

Worktrees are the right primitive because they are cheap. A full clone per session is slow and duplicates dependencies; a worktree shares the object store and costs almost nothing to create and remove.

The dirty-working-copy problem

The second failure is a session ending badly. An agent stops — hit a limit, hit an error, the user closed the window — leaving uncommitted changes in a directory nobody will look at again.

Two rules cover this:

• Every session ends with its work merged or pushed to a branch. Not “usually.” A branch with a work-in-progress commit is recoverable; a directory with uncommitted changes and no session attached is work you will find in three weeks and not be able to interpret.
• If committing is not possible, the session says exactly where the work is — repository, worktree, branch, and which files are dirty. A silent stop is the only genuinely unrecoverable outcome.

There is a related trap worth naming: never use the git stash to set work aside in a multi-session setup. The stash stack is shared across every worktree of a repository. One session’s git stash pop can restore — or destroy — another session’s work, and neither will know. A throwaway commit on the session’s own branch does the same job and cannot reach across sessions.

The context problem

The third failure is quieter and costs more over time. A session’s memory ends when the session does. Everything the agent knew — why this approach, what was already tried, what the constraint was — evaporates.

So the next session starts by reconstructing it, usually from you. This is the tax people describe as “re-explaining my project every morning,” and it scales linearly with how many sessions you run.

The only durable fix is that anything the next session needs must exist in a file:

• what is being built and why, maintained rather than rewritten;
• what this specific piece of work is, with its acceptance criteria;
• decisions already made, with their reasons, so they are not silently reversed;
• what was tried and did not work — the single most commonly lost item, and the one that causes the most repeated effort.

A useful test: could a new session pick this up cold, from the files alone, with no conversation history? If not, the missing part is the part you will be asked for tomorrow.

Handoff between sessions

Sequential sessions on the same piece of work need one more rule: the previous session must be provably finished before the next one starts in its worktree. “Probably done” is how two live sessions end up in one directory.

A clean handoff states what was completed, what remains, and where the work currently lives. If that cannot be produced, the previous session did not end — it stopped, which is a different thing and needs recovering rather than continuing.

When agents are interchangeable, sessions are the interface

There is a strategic reason to take this seriously beyond avoiding damage. If Claude Code, Codex, and OpenCode are interchangeable — and increasingly they are — then the durable part of your setup is not which agent you use. It is the discipline around the sessions: how work is isolated, how context persists, how handoffs happen, how completion is verified.

That layer is portable across vendors. Anything built into a single agent’s session format is not.

Where Arcadia fits

Arcadia Mission Control implements these rules directly: an isolated worktree per action, one live session per worktree, a refusal to work on the main branch, context maintained in files rather than conversations, and a required terminal state for every session.

It is experimental and in active development, with no customers yet. It currently governs its own development across Codex, Claude Code, and OpenCode — which is where most of these rules came from, usually after breaking one of them.

Arcadia Mission Control is the system described above. It is experimental, in active development, and has no customers yet — early users are helping decide what it becomes.

Last reviewed 2026-09-22.