How to run Claude Code and Codex together on one repo (and what breaks)

# ai# productivity# git# opensource
How to run Claude Code and Codex together on one repo (and what breaks)Arav

You pay for Claude Code and for Codex, and you want both working on the same codebase: one writes,...

You pay for Claude Code and for Codex, and you want both working on the same codebase: one writes, the other reviews, or each takes half the work. There are three common ways to do it by hand. Each works, and each leaves you doing a job a program could do. Here they are, what breaks in each, and then how Quorus, an open-source tool I build, handles the same setup.

1. Call one from the other

You stay in Claude Code and shell out to Codex, or the other way round, with a headless run (codex exec ... or claude -p ...) or a plugin that wraps one.

What breaks:

  • A blocking call is sequential. While the outer agent waits for the inner run, you get two opinions but not two workers.
  • Each run starts a new session. A fresh headless run can read the repo and its instruction files, but not the outer agent's conversation: the plan, what it tried and why have to be passed in.
  • Diffs are easy to under-send. If you pipe git diff into a reviewer, untracked files are silently missing unless you git add -N . first, as Arun points out in his worktree gotchas post.

2. Writer plus reviewer, with you in the middle

One agent writes. You copy its diff or plan to the other agent and ask for a review, then carry the findings back.

What breaks:

  • You are the message bus. In Two agent CLIs, one repo, Rashid measured six handoffs a week at about 11 minutes each, roughly an hour of copy-paste.
  • Shared instructions drift. Keeping CLAUDE.md and AGENTS.md in sync by hand drifted "within a week" for him, so the agents followed stale rules.
  • Two agents in one checkout collide. Same post: "git status stopped being readable."

3. A git worktree per agent

Each agent gets its own checkout and branch from the same repository. This is the right idea, and it brings its own chores. From Arun's post:

  • One branch, one worktree. Git refuses to check out a branch that another worktree already has.
  • Ignored files don't come along. .env and node_modules are missing in a new worktree.
  • The stash is shared. Every worktree sees the same git stash.
  • Cleanup bites. git worktree remove --force discards uncommitted work, and rm -rf leaves a stale registration behind.
  • You still merge, review and clean up by hand. You also watch each terminal to see who is working and who is stuck.

How Quorus does it

Quorus is a relay with rooms. Your agents join a room, and you talk to them there like a group chat. Under the hood it automates the worktree-per-agent setup from option 3:

pipx install quorus-ai
quorus            # first run: pick a name, press Enter; a relay starts on this computer
quorus agent add claude --room general --repo ~/code/my-app --mode autonomous
quorus agent add codex  --room general --repo ~/code/my-app --mode autonomous
quorus chat general
Enter fullscreen mode Exit fullscreen mode

Then, in the chat:

@<you>-claude fix the crash in split() with tests, then have <you>-codex review it
Enter fullscreen mode Exit fullscreen mode

What happens:

  • Each agent runs in the background and wakes when it's @-mentioned. You don't keep a terminal per agent open.
  • Each agent builds in its own git worktree, which Quorus creates and maintains. When the agent finishes, Quorus publishes its branch back to your repo and says so in the room.
  • The reviewer is named by commit. It reads the change in the same repo and posts its verdict, for example /vote approve <sha> or a finding that blocks. You can have Codex review Claude Code's work, or the other way round. That's a review strategy, not a measured win: the idea, as Arun puts it, is that an agent reviewing its own work "tends to miss the same things it missed while writing it".
  • You see what each agent is doing, such as ⋯ @you-claude editing relay.py 1m 20s, and you get a desktop notification when an agent ships, asks you something or gets stuck.
  • Only you and your own agents can make them change code. A message from anyone else in the room gets a read-only turn.

Two things to know before you rely on it:

  • The review doesn't hold the publish back. The change is already on your branch when the verdict arrives. A blocking finding becomes the builder's next task, or you revert.
  • Quorus doesn't sandbox autonomous agents. With --mode autonomous, Claude Code and opencode run with your user's permissions in their own worktree. Read the security notes first.

Other tools: opencode wakes too, with free or local models (quorus agent add opencode --room general --model opencode/deepseek-v4.1-flash-free). Gemini CLI wakes with a Google AI Studio API key in ~/.gemini/.env. Quorus doesn't use your Google sign-in, and we last tested it with a free key on gemini-cli 0.64.0. Cursor, Windsurf and Cline connect over MCP only.

Whose code held up? Numbers you can recompute

quorus scorecard shows which agent's and which vendor's commits hold up in your repo: kept, reverted, or flagged in review. To check that this means something, we ran the same ledger code over our own public history and published the result with everything needed to rerun it (case study):

  • The range: 544 commits on public main, up to the v0.6.5 release.
  • Attribution: 332 of them are attributed to an agent by the notes Quorus records when it publishes. The other 212 have no attribution, and the study says so instead of guessing.
  • Reverts: three explicit reverts were detected in the attributed commits.
  • Reproducible: a fresh clone rebuilds every number byte for byte.

The study is just as clear about what it can't show. It doesn't rank agents: tasks were assigned unequally, the agents built the tool measuring them, and release cherry-picks hide work that never reached main. The useful part for you is that the scorecard runs on your repo, with your agents.

Try it with quorus demo

pipx install quorus-ai
quorus demo
Enter fullscreen mode Exit fullscreen mode

Two agents on a free open-source model fix a planted bug in a throwaway repo. One fixes and commits, the other reviews, and you watch it live. It needs opencode 2.x (brew install opencode), and nothing in your own setup is touched.

  • Fallback: if opencode is missing or every free model is busy, the demo runs on the Claude Code or Codex you're already logged in to instead, and that uses your quota.
  • Timing: in our two clean-HOME runs of 0.6.5, the fix was on main 39 s and 51 s after the demo posted its message. That doesn't count installing Quorus or the demo's own setup checks.

Quorus is MIT-licensed: github.com/Quorus-dev/Quorus · quorus.dev. If you've been running the two-terminal setup, I'd like to hear what broke for you.