Migrate Claude Code to Codex: what /import carries over, and what your team keeps either way

To migrate Claude Code to Codex, run /import in an idle Codex CLI session, choose Claude Code, and pick what to bring: instruction files, settings, skills, MCP servers, hooks, project memories and up to 50 chats from the last 30 days. Since Codex CLI 0.165.0, released on 27 October 2026, imported Claude Code memories land in the new memory v2 store that fresh profiles now use by default.

That covers one person on one laptop, and it works well. What it does not cover is a team. Every import copies files from one machine's ~/.claude into the same machine's ~/.codex, so a team of eight that moves runs eight imports and ends up with eight private copies of eight private memories. Whatever the team agreed on and only Claude remembered was never shared to begin with, and the import does not change that.

What does Codex /import bring over from Claude Code?

OpenAI's import page lists the mapping as a table. As of 3 November 2026 it reads:

In the CLI you type /import, choose Claude Code or Cursor, then tick the setup, project files and recent chats you want. The CLI "imports up to 50 chats from the last 30 days". In the ChatGPT desktop app the same flow sits under Settings, Import, which can also import from Claude Cowork and has a switch to keep imported work in sync with the original agent. The page also says importing "doesn't change or delete your existing agent setup", so Claude Code keeps working afterwards and you can run the two side by side.

What changed in Codex 0.165.0?

The release note for 0.165.0 is one line: "Enabled memory v2 by default for fresh profiles and added support for importing external-agent memories into it." Two pull requests sit behind it. The first makes a fresh Codex home pick v2 when memories are switched on and no old memories directory exists. The second fixes imports, which "previously wrote only to the v1 workspace", so that imported resources now always go into memories_v2.

In practice: if you install Codex today, turn on memories and import from Claude Code, your Claude Code project memories end up under ~/.codex/memories_v2/. Codex memories are off by default, and the docs describe the files as "generated state" that you can inspect but should not treat as the place you edit by hand.

Where do your Claude Code memories actually come from?

Claude Code keeps two kinds, and they behave differently when you move.

• CLAUDE.md files. A project's ./CLAUDE.md is written by people and, in Anthropic's own words, "shared with your team through version control". The import maps instruction files to AGENTS.md, which is a plain file in the repo, so a teammate who pulls the branch gets it whether they run Claude Code or Codex. For how to write one that both agents read well, see how to write an AGENTS.md file.
• Auto memory. The notes Claude writes for itself under ~/.claude/projects/<project>/memory/, with a MEMORY.md index. Anthropic is plain about the scope: "Auto memory is machine-local." It is not in git and it is not on anyone else's laptop. More on that in does Claude Code have memory.

The import moves the second kind from one machine-local store into another machine-local store. That is the right behaviour for preferences like "uses pnpm" or "run the tests with the database up". It is the wrong home for "we chose Postgres advisory locks over Redis after the March outage", which is a team decision that happened to be learned by one person's agent.

Why does a team migration need more than an import?

Because a team does not switch on one day. For a few weeks some people are on Claude Code and some are on Codex, and the knowledge they produce in that time is split across two vendors' stores on a dozen machines. An import is a one-time copy at the moment you run it, so it cannot keep that window in sync between people.

This is where Baalda comes in, and it is the reason the migration gets smaller rather than bigger. Baalda is a team second brain built on plain markdown files: the decisions, runbooks and project notes live in a shared vault, every person's agent reads and writes those same files over MCP, and the vault does not belong to Claude Code or to Codex. Nothing in it has to be imported, because neither agent ever held it.

The one part of the vault that does travel with the import is the line that connects the agent to it. The MCP server configuration is a row in the import table, so a vault entry you added to Claude Code with

claude mcp add --transport http baalda https://api.baalda.com/api/mcp \
  --header "Authorization: Bearer mcp_…"

is carried into Codex's MCP configuration. The import page lists "MCP server settings that use custom authentication, headers, environment variables, or transports" among the things to review afterwards, and warns "You may need to sign in again". We have not confirmed exactly what the import writes for a header-authenticated server, so check it rather than trusting it.

What should you check in config.toml after the import?

Open ~/.codex/config.toml and find the vault's [mcp_servers.<name>] table. The shape Codex documents for a Streamable HTTP server with a bearer token is:

[mcp_servers.baalda]
url = "https://api.baalda.com/api/mcp"
bearer_token_env_var = "BAALDA_MCP_TOKEN"

Then export the token in your shell profile instead of leaving it in the file:

export BAALDA_MCP_TOKEN=mcp_your_token_here

For a vault on your own machine the URL is http://localhost:3010/api/mcp, and for a self-hosted server it is your server address plus /api/mcp. The full Codex setup, including enabled_tools to start with reads and additive writes, is in Codex CLI with a team second brain.

The token matters more than it looks. A Baalda MCP token belongs to one person, and every call made with it passes the same per-folder and per-note permissions that person has in the editor. So after the switch, Codex sees exactly what Claude Code saw, no more. Nobody has to redo access rules for the new agent.

What should move into the vault before you switch?

Before each person runs /import, spend ten minutes reading their Claude Code auto memory. Open ~/.claude/projects/<project>/memory/MEMORY.md and the topic files it points to. They are plain markdown, so this is quick. Sort each line into one of two piles:

1. Personal. Editor habits, how you like answers formatted, the shortcut you always forget. Let /import carry these into Codex memories. That is what they are for.
2. The team's. Decisions and their reasons, how a service actually behaves, the step that broke the last release. Ask Claude Code to write each one into the vault as a note, in the folder where the team keeps that kind of thing, before you switch. From then on Claude Code, Codex and the people on the team all read the same sentence, and anyone can correct it.

Skills follow the same split. A skill only you use can go across with the import. One the whole team relies on is better published once from the vault: the Baalda desktop app installs team skills into both ~/.claude/skills and ~/.agents/skills, the folder Codex reads, so it is already in place on the Codex side before anyone imports anything.

Where this does not help

Baalda does not migrate anything. It does not move chats, hooks, subagents, plugins or settings.json, and it has no opinion on whether Codex or Claude Code is the better agent for your code. /import is the right tool for all of that, and you should still run it.

It also only holds what someone writes down. A decision nobody moves out of auto memory before the switch stays on one laptop, in ~/.claude and now in ~/.codex as well. And MCP only reaches a synced vault: a vault kept on one machine with no account is as private as the memory files you were trying to get away from.