Using Claude Code and Codex together: ten days of practice

At the beginning of November my Claude quota was empty for two days. The work should not wait, so I kept building with Codex.

That worked. But I quickly noticed what was missing: the second agent only sees files and commits. What the first agent thought, decided and rejected is invisible to it.

Since then I have been deliberately working with Claude Code and Codex together. This is my practice from the first ten days. It is not a test and not a benchmark, just what has worked for me and what has not.

Codex vs. Claude Code: the wrong question?

If you search for "Codex vs. Claude Code" you find comparisons with benchmarks and price lists. They are useful when you have to pick one of the two.

I don't have to. I have both, and my real problem is a different one: how do I make sure two agents keep building the same project cleanly? For that, which model is better is secondary. What matters is what sits between them: where the rules live, how the state is handed over, and who works in which folder when.

Which agent is better for which task, I can't back up. I have too little practice and I haven't measured anything.

1. One instruction file for both: AGENTS.md

Codex reads a file called AGENTS.md in the project. Claude Code reads CLAUDE.md. If I had maintained the same things in both, the files would probably have drifted apart soon.

So my rule is: AGENTS.md is the single source. CLAUDE.md contains only a pointer to it plus whatever really concerns only Claude:

@AGENTS.md

## Claude Code only
- Preferred tools that Codex does not know

The @AGENTS.md line includes the file. From now on I write new project rules only into AGENTS.md, so every agent starts with the same rules.

2. A handover block instead of memory

The second agent does not know what the first one thought an hour ago. All it sees are files and commits. Everything else has to be written down.

At the top of my STATE.md there is a block called ## Handover. Whoever stops writes it before stopping:

## Handover
- Changed: what is different now (and which files)
- Half done: what was started but not finished
- Next step: one sentence, what the next one starts with
- Checked: which tests and checks ran, with the result

Whoever starts reads this block first. It can come from Claude Code or from Codex, it makes no difference as long as it is honest, above all under "Half done" and "Checked".

The block is unspectacular, but it replaces what a human colleague would tell you at a shift change.

3. Never two agents in the same folder

Two agents writing into the same directory at the same time are like two people typing the same sentence: in the end one overwrites the other's work without noticing.

My rules:

• If git status shows something that does not come from me or the current agent, or another session is running in the project, the second agent works in its own worktree.
• I always create worktrees inside the project under .worktrees/<name>/, not next to it. That way everyone knows later where they are.
• Otherwise only one agent works in the folder. A worktree is for real parallel work, not the default.

So that I don't forget who is working where, I built a small cockpit that also recognizes Codex sessions and warns me when both are active in the same project.

4. One builds, the other reviews

This was an unexpectedly good side effect. When one agent has drafted something, I let the other one read over it, with the task of finding gaps. In my weekly proposals for which project to push forward next, Claude writes the draft and Codex reviews it.

The reviewer has, for example, flagged claims in my draft that were not backed up. They stood there as facts although they were only assumptions. I corrected them. The agent that wrote a text rarely notices this kind of thing.

I don't know whether this is down to the two models or simply to the fact that a second look finds missing evidence. My impression is that switching helps. I haven't measured it.

5. Same tools, same knowledge

Both agents should have the same tools and the same knowledge, otherwise one works with more context than the other:

• The same MCP servers are registered in both, for example for searching my notes.
• Recipes live in files that both can read. I write them so that they make sense without Claude-specific tool names.
• Access to secrets goes through the same vault, not through two separate stores.

Pitfalls

These are the ones I actually ran into:

• Codex hooks need approval. A new entry in ~/.codex/hooks.json only runs after I have reviewed and confirmed it in Codex. codex exec silently skips hooks that have not been reviewed. "The hook is not called" then does not mean it is broken.
• Instruction files grow too long, fast. My global instructions therefore have a fixed size limit. Details live in topic cards that an agent reads only when a keyword matches.
• Memory is not a handover. If I rely on the agent "remembering", the other one has nothing. What is written down is what counts.

What I don't know

• Whether splitting the work would be better if I planned it by the strengths of the models. So far I mostly switch when a quota runs out.
• How this behaves with a team. I work alone.
• Whether my effort for handover and rules will keep paying off as both tools keep changing. Both change all the time.

It is ten days of practice, subjective, without measurement.

Take away

If you want to start tomorrow, four things are enough:

1. Create AGENTS.md as the only source for project rules; CLAUDE.md includes it with @AGENTS.md.
2. Put a ## Handover block at the top of STATE.md and write it before every stop.
3. Never two agents in the same folder, use a worktree instead.
4. Let the second agent review before anything important goes out.

Start small. The first two points take half an hour together and carry the furthest.