Coordinating Claude Code, Codex CLI & 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-08-08
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 Codex never edits a file Claude Code already holds — the collision is prevented, not merged later. 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 every agent's calls to the backend. You run it once per repo, 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 lock and how long its TTL runs, and picks non-overlapping work or messages Claude Code to hand off. Nothing reached a merge conflict, because nothing overlapping was ever written. Only metadata left the machines — the paths and lock claims above, never the code inside them.
When a tool doesn't speak MCP
Not every agent joins the protocol, and the room doesn't assume they will. The daemon streams each repo's git dirty-paths as heartbeats, so even an agent that never called vs_join shows up as a set of paths it's touching — and if those overlap a held lock, the room raises the conflict anyway. Coordination degrades to “we can still see what you're changing” 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 that stops the afternoon spent untangling three AI-authored versions 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.