Blog
Claude Code to Codex: what actually carries over
The guides all cover the same afternoon of configuration. Here is the part that is still missing a week later.
· updated 6 September 2026
Most of a Claude Code setup moves to Codex in an afternoon, because the parts that are files are portable: CLAUDE.md becomes AGENTS.md, the MCP servers are re-declared in a different config format, and your shell aliases do not care which binary they launch. What does not move is everything the agent knew that was never in a file - the findings, the ruled-out approaches, the reason a decision went the way it did. That material sits in one vendor's session history, no other tool reads it, and it is why a migration that looks finished on paper still feels like starting over on the first real task.
The half that is a file, and therefore moves
Instructions are the solved part, and they are solved because somebody standardised them. AGENTS.md is a cross-tool convention that a long list of agents read, so the usual first step of a migration is to copy CLAUDE.md across, or symlink one to the other and maintain a single file. The formats are close enough that most of it works unchanged.
MCP servers move too, though not by copying: each tool declares them in its own config, in its own format, and Codex in particular will not forward environment variables to a server unless they are named explicitly in that declaration. It is a re-typing job rather than a design job.
What is genuinely Claude Code's own - its hooks, its slash commands, its subagent definitions - does not have an equivalent to move to, and this is the part worth checking against current documentation rather than a guide, because it is where the tools differ most and change fastest.
- Moves with a copy: the instruction file, once renamed.
- Moves with a re-declaration: MCP servers, per tool, per format.
- Does not move: hooks, slash commands, and anything else with no counterpart on the other side.
- Never needed moving: your shell, your aliases, your worktrees.
The half that is not a file, and therefore does not
Ask what your agent knows that you never wrote down. That one module is a minefield and why. Which of the three obvious approaches was tried in March and abandoned. That the flaky test is flaky for an understood reason and is not worth chasing. Why a dependency is pinned. None of that is in CLAUDE.md, because it is not an instruction; it accumulated inside sessions, and it is the reason the agent had become useful.
That material is held by whichever vendor you were using, in a store no other vendor reads. Nothing about the migration is technically wrong when it disappears - it was never portable in the first place, and it would have been just as lost had you stayed and simply started a new session.
This is why migrations feel worse in week two than on day one. The configuration is done, the agent runs, and then you hit the first task that needed something the old setup had absorbed. There is nothing to copy across, because nobody wrote it anywhere.
Where the second half can live instead
The fix is not a better instruction file - putting findings there is exactly what makes CLAUDE.md unmaintainable, and it means paying context for them on every session regardless of relevance. The fix is a place outside both agents that either can read and write.
That is what a Thread is in Forkbench. One job gets its own folder, its own plan, its own notes and its own keys. An agent working in that Thread lists and reads the notes when it needs them, and files what it works out as it goes. Because the notes belong to the Thread rather than to the agent, quitting Claude Code and starting Codex in the same pane gives the new agent the same notes and the same board, with no migration step at all.
The notes are sealed on your Mac before they are stored, which is the part that makes this bearable to write down honestly: what makes the material portable between your agents does not make it readable by us.
Consider running both rather than switching
Most people asking this question do not actually want to leave; they want to try the other one. That is a smaller and safer move: give each agent its own git worktree so their edits cannot collide, put them in the same Thread so they share the notes and claim from the same board, and let the comparison happen on real work over a fortnight.
It also removes the deadline. If the second agent turns out to be better at one kind of task, you have not migrated - you have two agents, and the thing they both need is a shared place to write.
How to know the migration is actually done
Not on the first prompt, which will look fine. The test is the first genuinely awkward job: a debugging session on unfamiliar ground, or a change that touches the module everyone avoids. That is when a setup reveals what it had absorbed and you had stopped noticing.
Keep the old configuration until you have run one of those. It costs nothing to leave in place, and it is the only honest comparison available.
Related: Does Codex read CLAUDE.md?, Memory that survives a closed session, Running Codex CLI on a Mac
Frequently asked
Does Codex read CLAUDE.md?
No - it reads AGENTS.md. Copying or symlinking the file across is a minute's work, and it is the easy half of the move.
Is moving from Cursor to Claude Code any different?
The shape is identical: the rules file has a different name and a different location, the MCP declarations move by re-typing, and the accumulated understanding does not move at all. Only the file names change.
What happened to Gemini CLI?
Google retired the standalone Gemini CLI on 18 June 2026 for its AI Pro, Ultra and free tiers, replacing it with Antigravity CLI, which you invoke as agy. It remains reachable on paid Gemini API and Gemini Enterprise keys. If you are migrating off it, the same split applies: the instruction file moves, the accumulated context does not.
Can Forkbench convert my config for me?
No, and it deliberately does not try. It does not read, write or sync CLAUDE.md or AGENTS.md - those stay your agent's files. What it provides is the other place, for the material that should not be in either.