Codex /import Is a Moving Van for Your Agent's Memory

Codex CLI 0.145.0 switches on persistent memories and imports your whole Claude Code or Cursor setup in one command. Portability this convenient is usually how switching costs get built, not removed.

On July 21, Codex learned to remember. The same release taught it to take everything your other agents remember.

Those two features shipping together is the story. Codex CLI 0.145.0 added experimental thread history with persisted names, sub-agent support, and memories. And in the same release notes, one line down: the /import command now migrates Cursor and Claude Code settings, MCP servers, plugins, sessions, commands, and project-scoped memories. Not just your config. Your agent's accumulated knowledge of you and your projects.

OpenAI built a moving van. It's worth looking hard at which direction it drives.

Why memory is the layer that matters now

For most of the coding-agent era, switching tools was cheap. Your CLAUDE.md or AGENTS.md was a text file you could copy. Your MCP servers were a JSON block. The model behind the harness was a config value. The whole stack was designed, sometimes deliberately and sometimes by accident, to be portable.

Memory changes that. A memory store is the one asset that accumulates value the longer you stay. Every session teaches the agent a little more about your codebase's odd corners, your naming conventions, the deploy step everyone forgets. You can rewrite an instruction file in an afternoon. You cannot rewrite six months of accumulated context, because you don't remember most of what's in it. That's the point of it.

Which means memory is where the next lock-in fight happens. Vendors have mostly stopped competing on "our harness has feature X" because features get cloned in weeks. What can't be cloned is the store of context your agent built up inside one vendor's walls. The tool that holds your memory holds you.

OpenAI clearly understands this, because 0.145.0 attacks the problem from both ends at once: make Codex a place where memory accumulates, and make it trivial to bring the memory you accumulated elsewhere.

What actually shipped

The memories feature is more careful than I expected, and the official docs are worth reading in full. The design decisions:

Off by default. You enable memories in Settings > Personalization or with a [features] memories = true flag in config.toml. After the year the industry has had with surprise defaults, opt-in is the right call.

Local files, not a hidden store. Memories live under ~/.codex/memories/ as files holding summaries, durable entries, recent inputs, and supporting evidence from prior chats. You can open them and read them. The docs tell you to treat them as generated state rather than something you hand-edit, but inspectability matters, and this passes that bar.

Background generation with guardrails. Codex waits until a chat has been idle before summarizing it, skips short-lived sessions, redacts secrets from generated memory fields, and will skip a memory pass entirely if your remaining rate limit is below a threshold. There's even a memories.disable_on_external_context setting that keeps chats involving MCP tool calls or web search out of memory generation, which is a real prompt-injection precaution: content an outside party controlled never becomes a durable instruction.

Per-chat control. A /memories command lets you decide whether the current chat can read existing memories or contribute new ones.

Then there's the import side. The import flow detects your Claude Code or Cursor setup and maps it piece by piece: instruction files land in AGENTS.md, settings.json becomes config.toml, slash commands become skills, subagents become Codex agents, hooks come across as hooks, MCP configuration transfers, and your last 30 days of chats come along. One of the release's pull requests is titled "Preserve scope and provenance for imported agent memory," meaning a memory scoped to one project in Claude Code stays scoped to that project in Codex, with a record of where it came from. That's thoughtful engineering. Somebody cared about doing this well.

The docs also promise the import is non-destructive: your existing Claude or Cursor setup is left untouched. You're copying, not moving.

The direction of the van

Here's my position: /import is genuinely useful, and you should still be suspicious of it, because portable memory that flows one way isn't portability. It's acquisition.

Read the docs with direction in mind. There is an import flow, an import settings pane, a migration guide. There is no /export. Nothing in the release notes or the documentation describes moving your Codex memories, threads, or accumulated context out to another agent. The van drives toward Codex, parks, and stays there. (Claude's chat data is explicitly excluded too; the import screen notes standard Claude Chat data can't come over. The boundary runs both ways at the chat layer, but only one way at the setup-and-memory layer.)

This is the oldest playbook in platforms. Google Takeout made leaving Gmail theoretically possible and practically rare. Every social network ships a "find your friends from other apps" importer and none ships a "take your graph elsewhere" exporter with equal polish. The importer is a growth feature. It gets staffed, polished, and maintained because every successful import is a converted user whose exit cost just went up.

And the exit cost here compounds. The day you import, your context exists in two places and you've lost nothing. Six months later, the Codex copy has accumulated everything since, generated in Codex's own formats, consolidated by Codex's own models. The Claude Code copy is a snapshot of who you were in July. The asymmetry isn't in the import. It's in everything that happens after.

To be fair to OpenAI, the underlying stores are still local files, and local files can be read by anyone you point at them. This is a soft moat, not a hard one. But soft moats work. Nobody re-imports their context by hand twice a year on principle.

Put this into practice

Whatever agent you run, this release is a good excuse to figure out where your memory actually lives. The steps that cost the least:

Find your stores. For Codex, look in ~/.codex/memories/. For Claude Code, your CLAUDE.md files and anything your setup writes to ~/.claude. For Cursor, its rules and settings files. Open them. If you can't read what your agent knows about you, that's worth fixing before it grows.

Put the stores you own under version control. A private git repo holding your instruction files and memory directories costs nothing and turns "my context lives inside a vendor" into "my context is a repo I can point any agent at." You also get history, which matters the day a memory turns out to be wrong.

Keep rules out of memories entirely. OpenAI's own docs say this: keep required guidance in AGENTS.md or checked-in documentation, and treat memories as a recall layer, not the place rules live. A rule in a checked-in file is portable by definition. A rule that exists only as a generated memory is hostage to the store it sits in.

If you try /import, do the review the docs ask for. The import guide has a specific checklist: recheck tool permissions in imported skills and agents, re-authenticate MCP servers with custom auth, and verify imported hooks, because hook behavior may differ after import. A hook that behaved one way under Claude Code and subtly differently under Codex is exactly the kind of bug you find in production. Fifteen minutes of review is cheap.

Test the exit before you need it. Once a quarter, prove to yourself you could stand up your setup on a different agent from your own files. If the answer is yes, imports and vendors can come and go. If the answer is no, you've found your real dependency.

Where the argument is weakest

The honest caveats. Codex memories are experimental and off by default; this is a first version, and first versions of memory systems have a history of summarizing the wrong things. My lock-in reading is directional, not proven: OpenAI could ship an export flow next quarter and turn the moving van into an actual portability story, and the fact that memories are inspectable local files already puts this well ahead of an opaque hosted store. The import itself is non-destructive and well-engineered, and if you've been curious about Codex, it removes nearly all the friction of finding out; that's real value I don't want to argue you out of. And the strongest counterpoint: Claude Code's context lives in markdown you already own, so for many people the "keep a copy you own" advice describes what they're already doing without thinking of it as an exit strategy.

What I'd watch is whether an export ever ships, and whether the memory formats stay readable as the feature matures. Those two signals will tell you which story this is.

Your agent's memory is becoming the most valuable file on your machine that you've never read. Read it. Own it. Then let the vendors compete for the right to borrow it.

Sources: Codex CLI 0.145.0 release notes, Codex memories documentation, Codex import documentation.