Vendor wars used to play out in benchmark tables. This one is playing out in your .claude/ directory. OpenAI’s “Switch to Codex” push gives enterprises two free months of Codex usage plus a one-click importer that scans your machine for Claude Code’s skills, hooks, MCP servers, subagents, and instruction files and migrates what it can automatically. Anthropic’s counter-move wasn’t a competing exporter — it was raising Claude Code’s weekly usage limits by 50% for existing customers. That asymmetry is the actual story, and it tells you more about switching costs than either company’s marketing does.

I run Claude Code as my daily driver and maintain a moderately complex setup: custom skills, a handful of MCP servers, subagent definitions, project-level CLAUDE.md instructions. When a client asked me last week whether they should take OpenAI up on the free months, I actually ran the importer against a throwaway config instead of guessing. Here’s what happened.

What migrates cleanly

Plain instruction files transfer almost losslessly. CLAUDE.md-style project instructions are just markdown with some conventions — Codex’s importer reads them, restructures them into its own system-prompt format, and the semantic content survives. If your setup is mostly “here’s our coding style, here’s our test conventions, here’s the deploy process,” you’ll lose almost nothing.

Basic MCP server configs also came through fine — command, args, env var names (not values, which is correct behavior). If your MCP usage is standard stdio servers with documented setup, this is a non-event.

What breaks or degrades silently

Three categories gave me real trouble, and none of them failed loudly — they just produced worse behavior that I only caught by testing:

Hooks. Claude Code hooks are shell scripts wired to specific lifecycle events (PreToolUse, PostToolUse, Stop, etc.) via settings.json. Codex has its own event model that doesn’t map 1:1. The importer converted my pre-commit-style hook into something that ran, but at the wrong point in the loop — it fired after the diff was already staged instead of before, which defeats the entire point of a pre-commit gate.

Skills and subagents. These are the deepest Claude Code-specific abstraction — a skill is effectively a scoped, invokable capability with its own instructions and tool access. Codex doesn’t have a matching primitive; the importer flattened my skills into plain system-prompt text appended to the main context. That’s not migration, that’s context bloat. A skill I invoke maybe 5% of the time was now permanently consuming tokens on every single turn.

Anything referencing Claude-specific tool semantics. A few of my hooks and instructions assumed Claude Code’s specific tool names and permission model (e.g., checking whether Bash had been auto-approved for a pattern). These didn’t error — they just silently no-op’d, because Codex has different tool names entirely.

# what I actually did to evaluate the migration, not just trust the promo copy
mkdir -p /tmp/claude-export-test && cd /tmp/claude-export-test
cp -r ~/.claude/skills ~/.claude/settings.json ./  # throwaway copy, not my real config

# ran the Codex importer against this sandboxed copy
# then diffed BEHAVIOR, not just config structure:
# 1. Does the pre-commit hook still block on lint failure? -> NO, fires post-stage
# 2. Does the rarely-used skill still stay out of the default context? -> NO, flattened in
# 3. Do MCP servers still connect with the same env var names? -> YES

The lesson: a migration tool that reports “12 items imported, 0 errors” is not the same as “12 items imported correctly.” You have to test the behavior the config was supposed to produce, not just confirm the file exists on the other side.

Why Anthropic didn’t build an exporter

This is the more interesting strategic tell. Anthropic’s response — usage limit increases, not portability tooling — signals they’re betting that the switching cost itself is the moat, not feature parity. If Claude Code’s skills/hooks/subagent model is genuinely more expressive than Codex’s, then making migration easy actively hurts Anthropic, because a clean export would prove there’s nothing lock-in-shaped left to protect. Sweetening the deal for people who stay is the correct move if you believe your differentiation is real; building an exporter is the correct move if you’re worried it isn’t. Anthropic chose the first bet.

That’s a legitimate strategic read, but it does mean Claude Code users are, today, more locked in than the marketing about “open” agentic tooling would suggest. If your team standardizes deeply on skills/hooks/subagents, know that you’re accumulating switching cost, not just convenience.

What I’d actually recommend

Don’t take the free two months as a costless trial — budget real engineering time to verify each hook and skill’s behavior post-migration, not just its presence. If your Claude Code setup is mostly plain instructions and standard MCP servers, the switching cost is genuinely low and the free months might be worth it purely to benchmark Codex’s task loop against your workload. If you’ve built real depth in skills and hooks — anything where the behavior, not just the text, matters — treat that as sunk infrastructure investment and factor migration engineering time into any switching decision, not just the subscription price difference.

Takeaway

The importer answers “can I move my files” honestly. It doesn’t answer “will my automation still do what it did yesterday,” and that’s the question that actually matters for a production dev workflow. Test behavior, not file counts, before you commit a team to a switch — and go in expecting hooks and skills to be the parts that need hand-fixing, because that’s where the abstractions genuinely don’t map.

Sources: TechTimes: OpenAI vs Anthropic Coding War, Phemex: OpenAI Launches Codex Migration Tool for Claude Code Users, Bit.Fan: OpenAI adds Claude Code import to Codex, but users still can’t export their setup out