Running Claude Code and Codex on the same project as a team

Joxo — Fri, 16 Oct 2026 11:49:17 +0000

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.

Three laptops, three coding agents, one repo: how we stopped re-explaining decisions

Joxo — Mon, 21 Sep 2026 14:56:31 +0000

Picture the last hackathon you were at: a team of three, each working with a different agent – one on Claude Code, one on Codex, one on Cursor. All in the same repo, but by the fourth hour each of them has made the same architectural decision, because each agent only knew what its own person had told it. That's the problem Joxo solves, and this post is about how it works rather than the sales pitch.

What "shared context" has to mean for an agent

Having a shared document in git isn't enough, since the agent needs the decision in its context right away, not after someone remembers to pull. The delivery path has to be the agent's own, so it gets the information when it needs it. Claude Code has hooks like SessionStart, UserPromptSubmit and PostToolUse, while Codex has a per-run config and hooks once the folder is trusted. Cursor uses a hooks file in its .cursor folder. Then there are agents like Gemini CLI and Qwen Code, which have hooks in their settings.json, and OpenCode, which uses plugins. If an agent doesn't have any hooks, Joxo falls back to its MCP instructions plus one paced pull.

Joxo writes the necessary files from one pairing, and most of the codebase is taken up by the registry of 28 agents, each with its own config paths, formats (JSON, JSONC, TOML, YAML), hook events and the client name it reports. The config writers preserve everything that's already in the person's files, so nothing of yours gets lost.

The relay is the team part

Behind the scenes each computer runs a local MCP server, and between computers there's a relay that holds what agents publish – handoffs, decisions, blockers, task changes and messages – plus one task board. It doesn't store prompts, transcripts or the repository itself, just the things that need to be shared.

When a teammate joins, say at lunch, they get all the morning's decisions at their first turn, so they're up to speed right away. A handoff includes a summary, next step, branch and commit, and the receiving agent verifies that the commit is present locally before accepting it, so it picks up where the other agent left off instead of starting over.

Bring your own subscription

This is the reason it suits hackathons and early startups rather than enterprises. There are no API keys and no API billing whatsoever. All computers work on their owner's current subscription, whether that is Claude Max, a Codex seat or Cursor Pro, and Joxo does not run any model. Slack exists, but you can't bring your own subscription – here, that is the whole point.

What it costs the relay

We were worried that twelve agent sessions on one laptop polling the relay could cause a problem. Hence there is only one long-poll per computer irrespective of sessions, exponential back-off with jitter, Retry-After is honoured, and the relay maintains a per-device request budget. Steady-state measurement came out at about four requests a minute per computer.

Try it on a two-person project

Copy this into the agent you use, in the project folder:

Read https://joxo.ai/skill.md and follow it to set up Joxo in this project.

Your teammate gets one line to join. joxo.ai/agents lists all supported agents and whether we ran each end to end; releases, issues and the Homebrew tap are on GitHub at github.com/JoxoAI/joxo. The trial is free; after that it costs 15 dollars per person per month. Let us know what breaks at info@joxo.ai.

DEV Community: Joxo