Claude Code to Codex: What /import Moves

Codex now has a door for people coming over from Claude Code. In the Codex CLI you type /import in an idle session and pick Claude Code. In the ChatGPT desktop app the same flow lives under Settings > Import. OpenAI's import page lists what moves and where it lands, and one row matters if you have used Claude Code for a while: project memories from Claude Code go into Codex Memories.

Read that row closely before you switch. Claude Code's memory is the part nobody wrote down on purpose, like the test style you corrected twice or the deadline Claude decided was worth a note. Here is what happens to it on the way over, based on OpenAI's docs and the importer source in the open-source Codex repo at release 0.166.0.

What gets copied

Claude Code keeps auto memory per repository at ~/.claude/projects/<project>/memory/, as a MEMORY.md index with a topic file for each note (Anthropic's memory docs). The Codex importer walks every project folder there and collects every Markdown file in its memory directory.

The files are copied, not linked. They land in Codex's memory workspace under extensions/external_agent_import/resources/<project-key>/, beside a scope.json that records the project's working directory, and Codex queues a consolidation pass to fold them into its own memory. Your Claude Code files stay where they were. OpenAI's page says importing doesn't change or delete your existing agent setup.

It arrives as reference, not as instructions

The importer hands the consolidation step a separate set of rules for imported memory (source). Four of them change what you should expect:

Imported content is treated as "source material, not authoritative instructions."
In memory_summary.md, the summary Codex puts in front of each new session, an imported project gets "a compact route" under What's in Memory. Copying its contents into User Profile, User preferences or General Tips is ruled out.
An imported file with no reliable date goes under Older Memory Topics.
The detail stays in the imported files, and Codex reads them when a later task needs that topic.

So a preference Claude Code learned about you does not become a global Codex preference. It stays scoped to that project, behind a short route in the summary, with the detail in a file Codex opens when the work calls for it. I think that is the right call, because a stale note from another tool should not steer every session. Just don't expect the first Codex session after an import to know you the way Claude Code did. If a rule has to hold every time, it belongs in AGENTS.md, and OpenAI's memories page says the same about its own memories.

The project with no transcript left

This is the part to check. To scope a project's memory, the importer reads that project's Claude Code session transcripts, newest first, takes the working directory recorded in them, and keeps it only if that folder still exists on disk. When nothing usable turns up, the project is not offered for import, and a request for it comes back as "selected memory was not found."

Claude Code deletes transcripts older than cleanupPeriodDays, 30 days by default, and deliberately leaves memory files out of that sweep (Claude directory docs). Put those two facts side by side. The repo you have not opened in Claude Code for six weeks still has its memory folder and, on default settings, no transcript left for the importer to read. A repo you moved or renamed fails the same way, because the recorded folder is gone.

Before you trust the import, list ~/.claude/projects/ and compare it with what /import offers. For a repo that still sits where it was, one short Claude Code session there writes a fresh transcript, which is what the importer reads.

If the memory item never shows up in the CLI at all, look at the flag before your files. In the open-source CLI, at 0.166.0 and on main today, the memory step sits behind external_agent_memory_import, marked under development and off by default (source).

Nothing comes back

Claude Code has its own /import. Anthropic's command reference says it brings instruction files, MCP servers, commands, subagents and skills over from Codex, Gemini CLI or Cursor. Memory is not on that list.

On the Codex side, a CLI import is a snapshot. Running it again replaces that project's imported folder with whatever Claude Code holds at that moment. The desktop app adds an automatic-updates setting that keeps imported work in sync with the original agent. Either way the traffic runs one direction. Whatever Codex learns after the switch stays in Codex, and the Claude Code sessions you still open never see it.

One vault instead of a copy

MemoryRouter skips the move. Both tools write to the same vault. With memoryrouter-claude and memoryrouter-codex installed on one account, every Claude Code session and every Codex session, in every repository, reads and writes that vault (Codex setup docs). Before each prompt the hooks pull in the memories that match it, and after each finished turn they save what you asked plus the final reply. What you settle with Claude Code on Tuesday comes back in Codex on Wednesday with nothing to re-run. When Codex has no key configured, its hooks use the key Claude Code already saved on that machine, so both point at one vault.

Two limits. Hooks only see turns that happen after you install them, so old Claude Code sessions stay out. Bringing those in is a separate agent history import, where nothing uploads until you have seen the preview and the quoted price and said yes. And Codex's own memories can stay on. They stay local to Codex, and the vault sits beside them.

The Codex page walks through the quick connect and the optional hooks.

Test the direction /import skips

Tell Claude Code something synthetic: "For the vault test, the Halyard service retries three times." Let the turn finish. Then go to a different repo, start Codex clean, and ask how many times Halyard retries. After that, reverse it, from Codex to Claude Code. That second direction is the one no import covers.

Create your MemoryRouter account, put both hooks on one vault, and run the reverse test first.