Migrating from Claude Code to Codex: More Than Just Configuration

Migrating from Claude Code to Codex — configuration migration is actually the easiest part.

Codex can automatically detect and import CLAUDE.md, Skills, Commands, and Agents. But once you start working, there are still some things you’ll need to adjust manually, and you’ll need to rethink the division of labor between Codex and Claude.

This article documents that migration process.

I started migrating, not just to try something new.

Opus has been getting less usable lately, and while Fable is more capable, its price is too high. My industry is healthcare, and project requirements often involve words like disease, diagnosis, medication, which frequently trigger Fable’s safety mechanisms and cause automatic degradation to Opus.

Once the model switches, the quality and stability of executing complex tasks suffer. When this started to hinder daily development, I decided to gradually migrate project development to Codex.

I originally thought the most troublesome part would be moving CLAUDE.md, Skills, and various configurations. But when Codex opened the old project, it directly popped up an import window. Configuration was done in minutes — the things that needed manual handling actually came after the import.

How Does Codex Know This Is a Claude Project?

During my first migration, I didn’t manually copy any files or adjust configurations between two directories.

In the Codex App, click the + next to a project, select “Use existing project”, then open a project that previously used Claude Code. Codex automatically detects Claude configurations inside. Once recognized, the interface directly pops up:

Select settings to import

It identified four types of content in my project:

• CLAUDE.md

• Skill

• Command

• Agent

Select what you need, confirm the import, and the first step of migration is done. If you skip this window when opening the project, you can manually start migration later from Settings.

Both entry points do the same thing. When opening an old project for the first time, following the popup is the easiest. If you didn’t migrate then, or want to handle it later, go to Settings and manually import.

I had originally set aside half a day to handle configuration files, directory structures, and format differences. In practice, this part only took a few minutes.

So It’s Auto-Detected, Why Isn’t the Migration Complete?

After import, I first tested it on a repository I use for daily development.

This repo contains both frontend and backend code, as well as build/start scripts, documentation, and test scripts. In Claude Code, I had integrated some open-source Skills and tools, plus my own Commands and Skills — for example, a db-query command for database queries.

After migrating to Codex, project rules, open-source Skills, and tools were mostly recognized correctly. Codex could understand the frontend/backend directories and locate the repo’s build, start, and test scripts.

The problem came when I tried to call db-query: although the original Command appeared in the import results, it couldn’t be used the same way as in Claude Code.

In this test, the things that needed manual handling were Commands and CLAUDE.local.md.

Commands Are Recognized, But Can’t Be Used as Before

The import window can detect Claude Commands, but that doesn’t mean Codex will execute them the same way Claude Code did.

My original Command needed to be changed into a Skill. A Command is more like a shortcut, while a Skill contains a complete execution flow. When migrating, you can’t just look at the import list — you actually need to call it.

My approach was simple: I didn’t rewrite all Commands at once, only the frequently used ones. For each one I use, I convert it into a Skill. This also lets me clean out old Commands that haven’t been used in a long time.

CLAUDE.local.md Needs Special Handling

Another issue was CLAUDE.local.md.

Claude Code can use it to store personal or local rules without committing them to the project. This automatic import didn’t handle it. Content that needs to be kept should be moved to references via AGENTS.md.

You can’t skip this step. CLAUDE.local.md often contains personal paths, local commands, or preferences only for yourself. Merging it directly into the team-shared AGENTS.md would easily bring local configuration into the whole project.

So now I split content: rules everyone should follow go into the project-level AGENTS.md; content only related to my own environment stays in a separate file, and I reference it as needed.

One more thing to note: renaming CLAUDE.md to AGENTS.md isn’t enough. The old file often contains “patches” written specifically for Claude Code behavior, which may not be necessary after moving to Codex.

After import, I care more about two things: which old rules to delete, and which requirements to make more specific.

From CLI to App: How Big Is the Change?

Moving from Claude Code CLI to Codex App — the most obvious change is the interface.

Previously, most operations were done in the terminal. Now tasks, conversations, file changes, and execution progress are all in the UI, making it easier to view, switch, and preview.

Especially for design work like UI design or PPT creation, the App’s advantage is direct — no more constant switching between terminal, file manager, and preview tools.

But after using it for a few days, I think the difference isn’t that big. You’re still describing tasks, providing context, observing execution, and then verifying results. The UI changes the entry point and information presentation, not the basic logic of how an Agent works.

This actually reduced my migration cost. The habits of task decomposition and verification I developed in Claude Code CLI can mostly continue.

What needs adjusting is mainly the task organization in Codex App: when to interrupt, when to guide, when to queue new requests for the next round.

I wrote a separate article about these operations, so I won’t repeat them here. Going from CLI to UI takes some adaptation, but it’s not like learning a whole new tool.

I Didn’t Uninstall Claude Code

After migration, I didn’t rush to conclude “Claude Code vs Codex: which is stronger”, nor did I uninstall Claude Code.

Now my division of labor is clear:

• Project development gradually moves to Codex as the main tool.

• Tasks requiring long, deep reasoning temporarily stay with Claude.

• Content creation is also kept in Claude for now.

This split may not work for everyone, but it solves my practical problems. Project development values stable execution, rule inheritance, and process management — Codex fits my current needs.

Deep reasoning and creation are a different story. I don’t need to cram all work into the same tool just to say “migration complete.”

If you’re planning to migrate, you can follow this order:

• Use Codex’s import feature to bring over existing configurations.

• Pick a familiar small project to verify rules and commonly used Skills.

• Convert still-used Commands into Skills one by one.

• Check CLAUDE.local.md separately — don’t merge it directly into shared rules.

• Keep Claude Code for now. Use it for a while before deciding how to split tasks.

I also recommend starting with conservative permissions. A new tool can read old rules, but that doesn’t mean you know how it behaves in all scenarios. Run a few real tasks, then gradually open up — it’s easier than aiming for full automation from the start.

After Importing Configurations, How Do I Choose?

Looking back, this migration was simpler than I expected.

Codex can automatically detect CLAUDE.md, Skills, Commands, and Agents, saving a lot of configuration copying. The manual work mainly involves two areas: converting original Commands into Skills, and reorganizing local rules from CLAUDE.local.md.

I didn’t uninstall Claude Code. Project development is gradually moving to Codex, while deep reasoning and content creation temporarily stay with Claude.

After migration, I no longer obsess over which is stronger between Claude Code and Codex. For project development that needs stable execution, I use Codex; for deep reasoning and creation, Claude is still more suitable, so I keep it.

You don’t have to pick sides. If a tool can reliably get the job done, that’s enough.

Past articles:

• From Bare to Full Armor: 10 Essential Repositories for Claude Code
• The So-Called “Must-Have Skill List” Is Ruining Your AI
• I Turned My Headphone Remote Button Into a Voice Input for Doubao
• A SKILL Repository with 13 Files, Only 1 Truly Belongs to Me
• Testing the 78k-Star claude-mem: Cross-Session Memory Cuts Token Usage by Half
• College Application Helper: Try This Open-Source Xuefeng Agent
• 10 AI Writing Prompts That Make Output Actually Usable

Hi, I’m Niko, a lifelong learner. A 17-year programmer veteran, now using AI daily to write code and create. Here I share experiences of learning and using AI, technical thoughts, pitfalls encountered, practical tools, and Skills. Follow me to learn together.