---
title: "An unmerged branch, a stale main, and five sessions at 11:58 AM"
canonical: https://dxdev.com/blog/multi-agent-shared-checkout-safety/
datePublished: 2026-07-03
---
At 11:58 AM, five agent sessions were still live when we needed to advance `main` in the shared coordinator checkout.

The first thing that looked wrong was an unmerged feature branch. It had sat there long enough to invite the usual story: somebody finished a change, nobody merged it, and the repository is drifting. That wasn't what had happened.

The branch was parked at a checkpoint. Its tracker item was still in Backlog, and the change was intentionally not ready to merge. Meanwhile `main` itself could fast-forward cleanly. Those are three different facts, and treating them as one would have led us to the wrong operation.

The question was whether we could update the local `main` reference while five agents were active. Merging the feature branch was never on the table.

## The command we refused to run

The tempting command was also the unsafe one:

```bash
git checkout main
```

In a shared checkout, that changes the checked-out branch and updates the worktree. The risk was interrupting a live process that relied on the checkout staying where it was. A bad commit was never the concern.

All five sessions appeared, at first, to be working from the same place. They shared the coordinator checkout. If that was also where their implementation work happened, even a clean branch change would have been the wrong move, because we would be changing the ground under five running processes.

A normal checkout lost immediately. The feature branch was no merge candidate, and leaving `main` stale would have protected the worktree but left the coordinator repository behind a clean fast-forward. That left one operation worth considering: a no-checkout bump of `main`, which moves the branch reference without touching the files or the branch currently checked out in the shared workspace.

## Tracing where the edits actually happen

The safety argument came from following where each session executed its application work.

The answer was better than the first impression. The five live sessions used the shared checkout as a coordination surface, but each one did its actual work in a separate clone. The shared path held the operational context. The isolated clones held the edits.

That boundary is what made the bump possible. A Git ref update in the coordinator checkout can be safe while work continues elsewhere. A `git checkout main` in that same checkout would still be disruptive, because it changes the workspace the live sessions share. Isolated implementation clones don't make every Git command harmless. They make one narrow class of operation safe.

We wrote the decision down in that narrow form: the no-checkout `main` bump was safe while the five sessions ran, and a plain checkout was not.

## The order we checked things in

The implementation took almost no time. The reasoning did.

First we verified that the unmerged feature branch was parked at a checkpoint and not abandoned by accident. Then we checked that its tracker state agreed with that reading. Only after that did we confirm that `main` had a clean fast-forward path.

That settled branch state, but it said nothing about concurrency. For that we followed the execution topology. Which checkout did the agents share? Which paths held their actual edits? Could moving the local `main` ref touch either of those edit paths? The answer was no, because the work lived in separate clones and the update performed no checkout.

There is a bad version of this decision that sounds just as technical: "Git says it fast-forwards cleanly, so run it." That is branch reasoning, and it ignores the worktree. In a multi-agent system the branch graph is only half the state. The other half is the map of live processes to filesystems, and we needed both before touching `main`.

The invariant we ended up with was simple: don't change a shared worktree while agents may depend on it. Move a ref without a checkout only after proving that the agents editing code are isolated from that worktree. Five sessions can share one repository without sharing one editable surface, and that was the difference between a routine maintenance bump and a disruption we would have caused ourselves.

Before anyone changes a shared repository while automated agents are running, ask where each agent actually does its edits, and don't stop at which repository it points at. We've made "do not change a shared worktree while agents may depend on it" a written rule for any shared workspace.