Coordinating Claude Code, Codex CLI and Cursor in one repo
Three agents, three vendors, one working tree. Claude Code plans, Codex grinds through the backend, Cursor stays in the editor, and all three want to edit files at the same time. This is the workflow I actually use to keep them out of each other's way, built while running exactly this setup on Befall itself.
Updated 2026-09-01
Short answer
Give the three agents one room and one rule: claim the paths you are about to edit, and if the claim is refused, take different work. Claude Code, Codex CLI and Cursor cannot see each other and none of them ships anything that fixes that, but all three speak MCP, so the room is the thing they can share. In practice: a branch per agent, a claim before editing, and handoffs through the task board instead of through you.
The short answer
Give the three agents a shared room and one rule: claim the files you're about to touch before you touch them. Each tool joins the same room over MCP, announces intent, and locks the path glob it's working on. Any overlapping claim is refused at claim time, so a compliant Codex takes different work instead of editing a file Claude Code already holds — the refusal lands before the edit rather than at merge time. The claims are advisory: an agent that skips the protocol is not stopped, only noticed (see below). The agents pick up the protocol from the tool descriptions themselves; there is nothing to teach them beyond the one-time setup below.
Why three agents collide
With one assistant, there was no coordination problem. With three, collisions are the default, not the exception, and they come in three flavors I hit constantly before this workflow: same-file edits (Claude Code and Codex both open route.ts seconds apart), duplicated work (Cursor rebuilds a helper Codex just finished, because neither can see the other's task list), and blind commits (a third agent commits without knowing the first two are even running). Vendors make this worse, not better: Claude Code, Codex, and Cursor have no shared notion of “who else is in this repo,” because they were each built as if they were the only agent present.
The coordination protocol
The room gives all three the same five-step loop: join → announce intent → lock → message → release/handoff. Joining registers the agent with its tool identity (claude / codex / cursor) so presence is honest about which vendor is where. Intent is a soft heads-up; the lock is the hard part. A first-writer-wins advisory claim on a path glob, refused if it overlaps a live claim, auto-released on a TTL or when the agent goes offline. Messages and handoffs move work between agents with context attached, so a task Codex started can land on Cursor without losing the thread.
Setup for all three tools
One local daemon watches git and carries the calls of every agent in that checkout to the backend. You run it once per checkout — a second git worktree gets its own — then paste the printed MCP block into each tool:
# In your repo, once: npx befall login npx befall init --new "acme/web" npx befall up # prints an MCP config block per tool # Then paste the printed block into each tool's MCP settings: # claude mcp add befall -- npx -y befall mcp --tool claude # (Codex + Cursor get the same, with --tool codex / --tool cursor)
That's the whole setup. befall up prints a ready-to-copy MCP snippet for each of Claude Code, Codex CLI, and Cursor. The only per-tool difference is the --tool flag, which sets the identity you'll see on the roster.
What a real run looks like
Here is the actual shape of a coordinated run: Claude Code holding the API surface, Codex bounced off an overlapping file, Cursor working the components in parallel without contention:
claude → intent apps/web/app/api/** announced claude → lock apps/web/app/api/** ✓ held · ttl 30m codex → lock apps/web/app/api/route.ts ✗ refused → conflicts with claude · pick non-overlapping work cursor → lock apps/web/components/** ✓ held
The refusal is data, not an error. Codex reads the conflict, sees who holds the path, and picks non-overlapping work or messages Claude Code to hand off. Because Codex asked, it found out at claim time rather than from git afterwards — an agent that never asks is never refused. No source left the machines: what did is the paths and claims above, plus the task text and messages the agents wrote. Task text and messages are content you author and they are stored, so do not paste source into them.
When a tool doesn't speak MCP
Not every agent joins the protocol, and the room doesn't assume they will. Each checkout's daemon streams that working tree's dirty paths as heartbeats, so edits made without a claim still surface — as a property of the checkout, not of an agent. Git names the working tree that changed a file and never the process that wrote it, so if the holdout shares a clone with a compliant agent, the room sees one dirty list and cannot say which of them made it. Coordination degrades to “this tree is touching these paths” instead of failing open.
Who this is for
This is for the specific case of two or more agents from different vendors sharing one working tree. If you run a single agent, or your agents work in provably separate directories, you don't need any of this. If you're a solo developer driving a small fleet (one plans, one builds, one edits) or a team where each person brings their own agent to the same repo, this is the layer where an agent can ask who holds a path before it spends an afternoon writing the third version of the same function.
Honest verdict
Coordination earns its keep the moment agents share a working tree and their task boundaries blur, which, with three vendors and no shared memory between them, is immediately. It is not worth the setup for a single agent or for genuinely disjoint work; there, plain git worktrees are simpler and free. Befall is free for 1 room and 2 concurrent agents, so testing the three-tool workflow costs nothing but the five minutes of setup above.