Codex Is Importing Claude Code Setups Now. The Model War Is Becoming a Migration War.
OpenAI did not just add a few Codex features this week. It added a migration path.
That is the quiet part of the coding-agent market becoming loud. Models still matter, and nobody buying agent seats should pretend otherwise. But the higher-order fight is shifting from “which checkpoint wins SWE-bench?” to “which vendor can absorb your working setup with the least pain?” OpenAI’s latest Codex changelog names the target directly: users can now migrate supported setup from Claude Code and Claude Cowork into Codex. That is not a convenience feature. That is a switching campaign.
The June Codex updates are split across two related entries. On June 9, OpenAI added “Migrate to Codex” flows that import Claude Code and Claude Cowork setup during onboarding or from the settings surface. On June 11, Codex app 26.609 added Developer mode for Browser use, faster browser automation through Chrome DevTools Protocol and DOM snapshot optimizations, enterprise Computer Use expansion, plugin improvements, and rate-limit reset banking. Read together, the release says: bring your existing agent environment here, then give the agent enough runtime access to compete on real workflows.
The setup is the moat
A serious Claude Code setup is not a binary and a prompt. It is instructions in AGENTS.md or equivalent files, project-specific settings, MCP server configuration, hooks, slash commands, skills, subagents, approval habits, sandbox expectations, and a history of sessions that encode how the team works. OpenAI’s migration docs say Codex can detect and map a lot of that: instruction files, settings into config.toml, skills into Codex skills, recent sessions from the last 30 days into Codex threads or projects, MCP servers, hooks, slash commands, and subagents.
That list is the story. It is also a checklist of where coding agents have accumulated lock-in. The first generation of AI coding tools competed on autocomplete quality. The current generation competes on whether the agent understands your repo, your toolchain, your approval policy, your local conventions, and your tolerance for chaos. Once those pieces exist, asking a team to “try another agent” is no longer a clean A/B test. It is an environment migration.
OpenAI clearly understands this. Importing Claude Code setup lowers the cost of a weekend bake-off. It lets a skeptical team ask a sharper question: if Codex starts with roughly the same instructions, tools, and recent context, does it complete the same work better, faster, cheaper, or more safely? That is a much more useful comparison than opening two empty chat windows and asking both agents to fix a toy bug.
The dangerous part is not the copy operation
OpenAI’s docs include the right warnings. Users are told to review migrated setup, especially tool restrictions, MCP authentication, custom headers and transports, hooks, plugins and marketplaces, and prompt templates that rely on arguments, shell interpolation, or file-path placeholders. That warning should not be treated as legal boilerplate. It is the engineering reality of agent portability.
A hook that is safe in one runtime can be unsafe in another if it fires at a different point in the loop. An MCP server that worked under one environment may silently lose an auth header, inherit broader filesystem access, or fail closed in a way the agent interprets as missing data. Slash commands and prompt templates often contain assumptions about positional arguments, shell quoting, tool names, or current working directory. Subagents are even less portable: they encode expectations about context policy, delegation semantics, available tools, and termination behavior.
The right mental model is not “Codex imported my Claude Code environment.” It is “Codex generated a port of my agent environment that now needs code review.” Diff it. Run it in a non-critical repo. Validate the MCP servers. Check whether hooks still do what you think they do. Re-run a known task suite. If your team already has agent evals, this is exactly what they are for. If you do not, the migration flow just exposed the gap.
Browser Developer mode raises the ceiling and the blast radius
The June 11 update matters because migration is only half the pitch. Developer mode gives Codex controlled Chrome DevTools Protocol access in Chrome and the Codex in-app browser. OpenAI says this enables performance profiling, console and network inspection, runtime error diagnosis, DOM and page-state inspection, and deeper debugging. It also says Browser use is now up to 2x faster through CDP and DOM snapshot optimizations that reduce browser round trips.
For frontend and full-stack work, this is the difference between an agent guessing from screenshots and an agent reading the runtime. Console errors, failed network requests, hydration mismatches, layout state, timing data, and DOM snapshots are the raw material of real web debugging. Giving an agent that surface makes it materially more useful.
It also makes governance less optional. Browser internals can expose session state, tokens in local storage, internal URLs, customer data in rendered pages, and network payloads the agent does not need to solve the task. OpenAI says full CDP access requires explicit approval before inspecting a website and warns about sensitive browser internals. Enterprises should take that literally. Browser debugging agents need allowlists, per-site approvals, secret hygiene, logging, and replayable traces. “The agent can inspect the browser” is not one permission. It is a bundle of very sharp tools.
The same applies to Computer Use, which OpenAI is expanding for enterprise users outside the EEA, UK, and Switzerland with per-app access controls on Windows. Per-app controls are the correct shape. Agentic desktop access without application boundaries is not productivity software; it is an incident report waiting for a timestamp.
How teams should test this
If you are using Claude Code today, the useful move is not ideological loyalty. Run the import, but do it like a migration, not a demo. Pick three real tasks: one codebase navigation task, one browser/debug task, and one tool-heavy workflow that touches MCP or internal scripts. Run the same tasks in Claude Code and Codex with the imported setup, the same budget, the same approval policy, and the same reviewer. Measure completed work, human interventions, tool-call count, wall-clock time, cost, and the severity of mistakes.
Do not overfit to a single “won/lost” answer. The agent that produces fewer changes but cleaner diffs may be better for core code. The agent that uses CDP well may win on frontend debugging. The agent that preserves MCP schemas and warns cleanly about scoped startup failures may be safer for internal automation. Model quality is now entangled with runtime quality, migration quality, and permission design.
That is the real takeaway from OpenAI’s update. Coding-agent competition is no longer just a leaderboard race. It is becoming a migration war, and migration wars are won by the vendor that makes switching feel reversible while quietly inheriting the workflow. Importing Claude Code setup is a shot across Anthropic’s bow, but the serious question for builders is simpler: after the import, can you still explain what the agent is allowed to do?
Sources: OpenAI Codex changelog, OpenAI Migrate to Codex docs, OpenAI Codex Browser Developer mode docs, Codex CLI 0.139.0 release