Most guides on using Claude Code and Codex together assume one person at one keyboard with two terminals. That setup is easy. The hard version is two or three people, each on their own laptop and their own plan, one using Claude Code and another using Codex, all pushing to the same repo.
With one person, everything the agents don't know is still in that person's head. A team doesn't have that. Each agent knows what its own person told it, and nothing else. By Wednesday two agents have made the same decision two different ways and nobody noticed, because the PRs touched different files.
Here's the setup we've settled on after a lot of running mixed teams of agents on one repo. None of it needs special tooling.
1. One instruction file, read by both
Codex reads AGENTS.md. Claude Code used to read only CLAUDE.md, so teams kept two files and they drifted apart. Since Claude Code 2.1.277 that's no longer needed: in a folder with no CLAUDE.md, Claude Code reads AGENTS.md instead. You can change this under "Project instructions" in /config.
If you have Claude-specific instructions, keep CLAUDE.md as a single import line plus the extras:
@AGENTS.md
## Claude Code only
- Use the test runner script, not the raw test command.
An import is better than a symlink: it works on Windows without Developer Mode and it survives tools that copy files around.
Keep AGENTS.md short. It should hold the rules every agent needs on every task: how to run tests, where things live, what never to touch. Anything that changes week to week goes in the files below.
2. Claim before you plan
The most expensive failure on a team isn't a merge conflict. Merge conflicts are loud. The expensive one is quiet: two agents pick up the same bug from a chat message and fix it in opposite directions. One adds retries, the other removes them. Both PRs are green, no lines overlap, and you find out in production.
The fix is a claim that happens before any planning:
- If you use GitHub issues, the agent assigns the issue (or opens a draft PR that names it) before writing a plan.
- If you use a
TASKS.md, the agent writes its person's name next to the task and pushes that one-line change first.
Put the rule in AGENTS.md: "Before planning, claim the task. If someone else holds it, stop and pick another." Agents follow this well once it's written down. They just won't do it on their own.
3. Decisions get one dated line
Code review catches bad code. It doesn't catch a decision made in someone else's session three days ago that your agent has never heard of.
Keep a DECISIONS.md with one line per decision:
2026-10-14 Retries live in the HTTP client only, never in callers. Rejected: per-call retry flags (hid failures). PR #212
2026-10-15 Postgres for jobs, not Redis. Rejected: Redis streams (one more thing to run). PR #219
Two details matter more than they look. First, the rejected alternative: that's exactly what the next agent will propose, with confidence, unless it can read why it was turned down. Second, the rule that agents read this file at the start of every session, not when someone remembers. Put that in AGENTS.md too.
A decision that changes behaviour for other code (retry policy, schema, API shape, auth) isn't made until it's written here.
4. Handoffs name the branch and the commit
People stop mid-task: end of day, a meeting, a laptop that went to sleep. On a team, the next person's agent often picks it up. A handoff that says "auth mostly done" costs the next agent twenty minutes of rediscovery, or worse, a fresh start on stale code.
A useful handoff has five parts:
Done: login + refresh tokens, tests passing
Next: logout endpoint, then revoke on password change
Don't touch: token format (see DECISIONS 10-15)
Branch: feat/auth Commit: 3f9c2e1
Open question: session length, ask Sara
The commit is the part people skip, and it's the one that saves you. The receiving agent can check it has that commit locally before it builds on anything.
5. Let the vendors review each other
This is the real upside of a mixed team. A model reviewing its own work tends to miss the same things it missed while writing it. A different vendor's model brings different blind spots.
Both CLIs have a non-interactive mode, so cross-review is a one-liner. From a Claude Code session:
codex exec "Review the changes on this branch against main. List bugs and risky changes only."
And the other way round, from wherever Codex is working:
claude -p "Review the diff between main and this branch. Bugs and contract changes only, no style notes."
Each command runs on the account of the person whose machine it's on. That brings up the one rule that isn't about files.
Everyone on their own plan
Each teammate signs in with their own Claude or ChatGPT/Codex subscription. Don't share logins: it breaks the providers' terms, and you lose any record of whose session did what. If one person's agent hands work to another person's agent, that's collaboration. The work then runs on the receiving person's plan.
It also keeps costs honest. Each person knows what their own usage is, and nobody's limits depend on someone else's afternoon.
Split by area, write contracts first
Last habit, and the simplest. Agents do better when they own an area than when they take turns on the same files. One person's Claude Code takes the frontend, another's Codex takes the API, and whatever crosses the line (request shapes, env vars, error codes) gets written down before either starts. A CONTRACTS.md or an OpenAPI file both agents read is enough.
What this looks like day to day
Four files (AGENTS.md, TASKS.md or issues, DECISIONS.md, a handoff note) and three rules in AGENTS.md: claim before you plan, read decisions at start, write a handoff when you stop. That covers most of the coordination a small team needs. The cost is discipline: someone has to notice when an agent skipped a step.
Where Joxo fits
Disclosure: I'm building Joxo, so read this part with that in mind.
Joxo covers the claim, decision and handoff habits above without the files. Claude Code, Codex, Cursor and other agents work in one project and one chat with the team. When one agent claims a task, the others are told who has it. Decisions and handoffs (with the branch and commit) are shared across everyone's agents, and agent sessions can message each other by name. Each teammate's agent runs on that person's own computer and plan, with no API keys. There's also an iPhone app in TestFlight beta that pings you when an agent is waiting on you.
It's $15 per person per month after a 14-day trial that needs no card, at joxo.ai. If you'd rather keep the plain files, that works too. The point is that the claims, decisions and handoffs exist somewhere every agent reads.
