Claude Code vs Codex CLI: One Item Out of Nine Imports

Claude code vs codex cli is usually argued on feature lists that converged a year ago. The question that actually costs you a day is what your configuration does when you move, so we ran Claude Code's own importer against a real Codex install: ~/.codex holding a 3,988-byte config.toml with 14 project entries, 12 plugins, two marketplaces, a hooks block and one MCP server. One item imported. Eight had no mapping. Two keys were reported in neither list. Our best AI coding assistant comparison covers the wider choice; this measures the cost of changing your mind.

Key takeaways

• claude import codex --dry-run on 2.1.274 reported 1 importable item against 8 with no automatic mapping.
• The one item that transfers is an MCP server. No instruction file, no hooks, no project settings.
• model and model_reasoning_effort are set in config.toml and appear in neither the importable nor the unmapped list.
• A directory holding only AGENTS.md adds exactly one project-level item; README.md and CLAUDE.md add none.
• The same AGENTS.md scores +1 through the codex source and +0 through cursor, in the same directory, minutes apart.

Claude code vs codex cli: the decision that costs a day

Both are terminal agents, both edit multiple files, both run commands, both speak MCP. We measured the outbound direction in August: Claude Code vs Codex CLI: What Actually Ports Between Them found 10,916 bytes of committed agent config in this repository and Codex reading none of it.

This article is the return journey, and it is a different measurement because Claude Code has an importer and Codex does not. codex is one of exactly three sources it accepts — alongside gemini and cursor — so this is the most supported migration path Anthropic ships. Knowing what the best-supported path carries is how you price the others.

Both tools are installed here: Claude Code 2.1.274 and codex-cli 0.152.1, with a ~/.codex that has been in use long enough to accumulate 14 project trust entries.

What the importer found in a real Codex home

claude import codex --dry-run
# → Importable (1 item, user-level):
# →   - An MCP server named node_repl
# → No automatic mapping (8 items):
# →   - hooks, service_tier, notify, projects, windows,
# →     desktop, marketplaces, plugins

Nine reported items, one of which moves. The eight that do not are not obscure corners — they are the hook definitions, the per-project trust levels, the plugin enablement and the marketplace sources that make a Codex install yours.

The hooks entry is the only one that comes with a reason. Codex and Claude Code use different hook event names, so the tool tells you to re-add them by hand under the hooks key in settings.json rather than guessing at a translation. That is the right call — a silently mistranslated hook is worse than an absent one — and it is also a fair summary of the whole exercise.

The two keys reported in neither list

This is the finding we did not go looking for. Our config.toml opens with four top-level scalar keys before the first table:

model = "<MODEL_ID>"
model_reasoning_effort = "<EFFORT>"
service_tier = "<TIER>"
notify = ["<COMMAND>"]

service_tier and notify both appear in the unmapped list. model and model_reasoning_effort appear nowhere — not among the importable items, not among the unmapped ones. The two settings that decide which model runs and how hard it thinks are the two the report does not mention.

We are careful about what that shows. It demonstrates that the two keys are absent from both lists in the report, which is what we observed; it does not establish whether they are deliberately excluded as non-portable or dropped by oversight. Either way the practical consequence is the same and it is the reason this section exists: a reader who trusts the eight-item list as complete will assume their model choice is accounted for.

Four arms, one file at a time

The project-level half of the scan is reproducible on any machine, so we ran it as a controlled experiment rather than a single observation. Four empty directories, one file different in each, the same command in all four.

The user-level half — the one MCP server — was constant across all four, which is the control that says the difference is the directory and not the run. The digest is the importer's own confirmation token, and it moving is independent confirmation that the scan result actually changed rather than the wording drifting between two model-authored summaries.

CLAUDE.md scoring zero is worth its own line. The codex source is looking for Codex's project surface, and Claude Code's own instruction file is not part of it — reasonable, and not what most people would guess.

The same AGENTS.md scores differently per source

We then ran the other two supported sources against the same directory, still holding nothing but AGENTS.md:

• claude import codex --dry-run → "1 project-level item from this repo's agent config directories"
• claude import cursor --dry-run → "Nothing project-level was found."
• claude import gemini --dry-run → "No importable agent config found."

One file, one directory, three sources, three different readings. That extends rather than contradicts what we measured in the Cursor migration audit on 2026-09-16, where a four-file .cursor/ fixture scored AGENTS.md at +0 while the legacy .cursorrules scored +1. The cursor source steps over the file; the codex source counts it.

The practical version: AGENTS.md is the most portable instruction file in this ecosystem, and whether a migration tool sees it depends entirely on which source you name. Our four-arm AGENTS.md probe covers the other half of that story — the file reaching Claude Code's model at all requires an explicit @AGENTS.md import, whatever the importer says about it.

Found is also not imported. Project-level items are held back from --yes entirely, with the stated reason that project config can be authored by anyone with repo write access. To act on that one item you need the terminal picker.

Why this is not a committed fixture

Our Cursor measurement ships a committed fixture project, so anyone can re-run it. This one cannot, and the reason is a null result worth publishing.

We built a fixture Codex home containing a single MCP server named fixture_only, pointed CODEX_HOME at it, and re-ran the import. The scan reported node_repl — the real home's server — and returned the real home's digest, cd3c130ae5022ef3d47df8145e866f9b. CODEX_HOME does not redirect the scan. The fixture was read straight past.

So the project-level half of this experiment reproduces anywhere and the user-level half reproduces nowhere but this machine. npm run check:codex-import reflects that split honestly: it re-reads the live ~/.codex to confirm the config still has the shape the article describes, and guards the recorded runs for internal consistency rather than pretending it can replay them.

npm run check:codex-import
# → ~/.codex/config.toml  3,988 B · 34 tables
# → Scan                  1 importable · 8 unmapped · 2 reported in neither list

Codex or claude code: which to run

• You already have a configured Codex install. Staying is cheaper than moving. One MCP server transfers; 14 project entries, 12 plugins and your hooks do not.
• You are starting fresh. Write AGENTS.md first. Codex reads it natively, Claude Code reads it through one @AGENTS.md line, and it is the only instruction surface both tools share.
• You want the widest migration support. Claude Code, by default — it imports from three sources and Codex imports from none. Just price "supported" at what this article measured.
• You want an open source agent. Codex CLI is Apache-2.0 and anthropics/claude-code publishes no SPDX licence, a gap we measured against a dormant Aider in the same week.
• You care about where MCP config lives. Codex keeps servers in a home-level config.toml; Claude Code reads a project-scoped .mcp.json that arrives with a git clone. That difference decides whether your teammates get your servers.

What we could not measure

Nothing was written. Every run recorded here carries --dry-run. We did not execute a --yes import, so we cannot describe what the resulting settings.json looks like or confirm that the reference skill lands where the tool says it will.

No output-quality, latency or cost comparison was attempted. Both agents are installed, so it was technically possible and we still did not do it — a head-to-head across two model families and two harnesses needs far more control than a config census, and the fixture guards against any later edit quietly adding one.

The scan report is prose, not a machine-readable result. The importer answers in sentences, and the wording differed between runs that produced identical digests. We treated the digest and the item counts as the signal and the phrasing as incidental, which is why the arm table records both.

Two keys being absent from both lists is an observation, not a diagnosis. We did not read the importer's source, and we make no claim about whether that is intentional.

Common mistakes

• Reading "supported source" as "supported migration". Codex is the best case Claude Code offers and it moved one item out of nine.
• Trusting the unmapped list as exhaustive. Two of our four top-level keys appeared in neither list. Diff your own config.toml against the report.
• Assuming a found item will import. Project-level items are found, reported as held back, and excluded from --yes. They need the terminal picker.
• Expecting CLAUDE.md to count. It scores zero through the codex source. The file that counts is AGENTS.md.
• Generalising one source's behaviour to the others. The same file scored +1 through codex and +0 through cursor in the same directory.

Conclusion

For claude code vs codex cli, choose on what you want to run rather than on what will move, because the answer to the second question is roughly nothing — one MCP server on the best-supported path Anthropic ships. Put your instructions in AGENTS.md today whichever tool you use; it is the one file both read and the only thing that makes this decision reversible. Then read what happens to a Cursor config next, where the same file scores zero and the legacy one scores one.

Frequently asked questions

Muhammad Kashif

Founder and editor of Devventa, covering AI coding assistants, Next.js and the modern AI development stack.