A Conflict-Free Multi-Agent Ensemble for Claude and Codex | by Hideaki Takahashi | Jul, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

A Conflict-Free Multi-Agent Ensemble for Claude and Codex

Hideaki Takahashi

8 min read·<br>Just now

Listen

Share

Press enter or click to view image in full size

Two agents on one task used to mean two agents fighting over one branch. h5i team gives each its own sealed worktree, lets them peer-review each other, then a neutral verifier replays every candidate and merges only the one that passes. It all rides in your Git under refs/h5i/team, no SaaS.

The problem with running more than one agent<br>Running a single coding agent is now routine. Running several, say Claude Code and Codex on the same task so you can take the better answer, is where it falls apart. The moment two agents share a working tree or a branch, they start stepping on each other:<br>Agent B’s edit lands on top of Agent A’s half-finished change and silently clobbers it.<br>A git operation one agent runs mid-flight leaves the other looking at an inconsistent tree.<br>When both are “done,” you’re left diffing two tangled sets of changes by hand, with no principled way to say which one is actually correct.<br>The obvious fix is to give each agent its own Git worktree. It isn’t enough. A worktree separates Git’s working directories, but it is not a sandbox: every worktree is just a sibling directory on the same filesystem, and a process in one can happily write into ../another-agent/, or over your main checkout, through a relative path in a build script. In one documented case, Claude Code, running inside its own worktree, followed a README's ./build.sh, and the script's relative path (../repo/published/) overwrote hand-crafted files in the parent repo. The agent did nothing malicious; it just executed the steps it was told to. Separate clones have the same filesystem gap and also drift out of sync, losing your prompt and context history. And even once the boxes stop colliding, picking a winner by eyeballing two diffs is exactly the safe acceptance problem that makes multi-agent work slow in the first place.<br>h5i team treats this as an orchestration problem with three requirements: isolate so agents can't collide, coordinate so review actually happens, and gate so only verified work merges.<br>Isolation is the whole trick<br>Press enter or click to view image in full size

The load-bearing idea is that no two agents ever touch the same branch, and no agent can reach another’s files. That is why an h5i env is a worktree and a sandbox, not just a worktree. Each agent gets its own branch under refs/h5i/env/... so there is no shared Git state to collide on, and its box confines filesystem writes to its own $WORK, so it cannot reach a sibling agent's tree or your main checkout the way a bare worktree can. Permissions stay off inside the box.<br>Conflict isn’t managed here, it is structurally prevented at two layers, Git and the filesystem. There is no shared mutable state to race on and no relative path out of the box. The only route any change takes to your branch is the verify → apply gate at the end, and that gate merges exactly one reviewed, tested result.<br>The lifecycle<br>Press enter or click to view image in full size

A team moves through a small set of phases. You drive the setup and the finalization; the agents do the work in between, and the coordination hooks keep them honest.<br>1. Wire the hooks once<br>The --team flag registers the peer-review coordination hook. This is a one-time setup, committed so your teammates inherit it.<br>$ h5i hook setup --write --wrap-bash --teamThe team hook is a Stop hook for both Claude Code and Codex. It keeps an agent from stopping while it still owes work in an active round, and surfaces review requests to it between turns, so peer review happens as part of the run instead of something you orchestrate by hand.<br>2. Create a box per agent, and a team<br>Each agent gets its own sandboxed environment; the team ties them together against a common base commit.<br>$ h5i env create claude-env --profile agent-claude<br>$ h5i env create codex-env --profile agent-codex$ h5i team create qsort-demo --base HEAD<br>$ h5i team add-env qsort-demo env/human/claude-env --runtime claude<br>$ h5i team add-env qsort-demo env/human/codex-env --runtime codex<br>$ h5i team status qsort-demoteam qsort-demo (qsort-demo)<br>phase : draft<br>base : 1b7d294fa063<br>agents : 2<br>submits : 0<br>- milo working env/human/codex-env<br>- nina working env/human/claude-envh5i hands each agent a short, friendly key; here they are milo and nina. Note them, you'll use them at verify time.<br>3. Dispatch one task to everyone<br>The task is piped in on stdin and delivered to every agent in the team.<br>$ echo "Implement Quick Sort from scratch in Python." | h5i team dispatch qsort-demo✔ dispatched to 2 agentsThen launch each agent inside its own sandbox. h5i team bootstrap hands the agent the dispatched task automatically, so both start...