How to Share Memory Between Claude Code and Codex

To share memory between Claude Code and Codex, connect both tools to one shared memory store over MCP. Each tool keeps its own local session, but both read from and write to the same external store: load relevant context with get_context at the start of a session and save the exchange with save_turn at the end. That way context survives every tool switch.

If you use Claude Code for frontend work and Codex for backend work (or split tasks between them any other way), you have felt the tax: you explain the architecture in Claude Code, switch to Codex, and start over. Both tools are stateless across each other. Neither can see the other's conversation history, and neither was designed to. The fix is not a better prompt; it is a shared memory layer that both tools can reach.

Why does each tool keep its own context?

Claude Code and Codex are separate applications with separate conversation stores. Claude Code keeps its sessions locally (or in its own cloud, depending on your setup), and Codex keeps its own. There is no built-in sync between them, because they are products from different vendors with no shared account or shared state.

This isolation is deliberate. Each tool optimizes for its own session: fast local recall, per-project settings, and its own permission model. But it means anything you decided, tried, or learned in one tool is invisible to the other. Copy-pasting between them works for a day and collapses the moment the context gets large or the handoffs get frequent.

What is the shared-store pattern over MCP?

The shared-store pattern gives both tools a single external memory they can both read and write through the Model Context Protocol (MCP). Instead of each tool hoarding context in its own silo, you add one MCP memory server to both tools' configurations:

1. Install or subscribe to one memory store that exposes MCP tools.
2. Connect Claude Code to it and connect Codex to the same account or database.
3. At the start of each session, the agent pulls relevant context from the shared store.
4. During the session, the agent works as usual with its own local tools.
5. At the end (or at meaningful checkpoints), the agent saves decisions, outcomes, and open tasks back to the shared store.

The next session, in either tool, starts with the full picture: what was decided, what failed, what is still open. The tools themselves do not change; the memory layer sits underneath both of them.

How do I set this up, step by step?

1. Pick one shared store. It can be self-hosted (a local MCP memory server backed by files or SQLite) or cloud-hosted. The only hard requirement: both Claude Code and Codex must be able to reach it over MCP.
2. Connect Claude Code. Add the memory server to your Claude Code MCP configuration and approve it. Run a quick test: ask it to save a fact ("the API base URL is X") and recall it in a new session.
3. Connect Codex to the same store. Use the same account, API key, or database path, so both tools point at the identical backend. This is the step people get wrong: two separate databases means two separate memories.
4. Establish a save habit. At minimum, save at the end of each session: the goal, the key decisions, what was tried and what failed, and what remains open. Some setups save automatically on every turn; if yours does not, make the final message of each session a save.
5. Establish a load habit. Start significant sessions by asking the agent to pull relevant context first ("check shared memory for this project before starting"). Retrieval should be selective, not a full dump; a good store returns what is relevant to the current task.
6. Verify the handoff. Make a change in Claude Code, save it, then open Codex and ask it to recall that change. If it can, the loop is closed.

What should I sync vs. keep tool-local?

Not everything belongs in shared memory. Sync the durable stuff: architecture decisions, API contracts, naming conventions, project goals, task lists, failed approaches worth not repeating, and reusable procedures. Keep tool-local the ephemeral stuff: the exact file paths you are mid-edit on, scratch reasoning, and anything sensitive you would not want every future session (in either tool) to see.

A useful rule: if you would want to know it three weeks from now in the other tool, save it to the shared store. If it only matters for the next ten minutes in this session, leave it local.

How do I handle conflicts when both tools write?

Conflicts are inevitable: Claude Code decides the auth approach is X, Codex later decides it is Y. The sane default is last write wins, with recency-aware retrieval so the newest version is what the agent sees. When you change a decision, state it explicitly once ("we are no longer doing X, we are doing Y") and save that; the correction propagates to both tools because they read the same store.

For genuine disagreements rather than updates, keep both versions with timestamps and sources, and let the current session's agent reconcile them. What you must avoid is silent divergence: two tools holding two different "truths" with no record of the conflict.

Which shared store should I use?

If you want zero infrastructure to manage, Vilix AI is a cloud-hosted shared memory store that both Claude Code and Codex read over MCP, so one memory follows you across tools and devices. The honest tradeoff is that it is cloud-only: your memory lives on hosted infrastructure rather than your own machine, which is the right call if you value zero setup and the wrong call if you need everything local. Self-hosted MCP memory servers are the alternative when local-first is a requirement.

FAQ

Do I need to change how I use Claude Code or Codex? No. Both tools work exactly as before. You add one MCP server to each, and the memory layer handles the rest. Your prompts, workflows, and keybindings stay the same.

Will this slow down my sessions? A well-built store retrieves only relevant context, not the whole archive, so the added latency is one tool call at session start. If a store dumps everything into context, switch to one with selective retrieval.

Can I share memory across more than two tools? Yes. The pattern scales: any MCP-compatible tool pointed at the same store joins the shared memory. Claude Code and Codex are just the start; the same memory can follow you to Cursor, your phone app, or a headless agent.

What happens if I delete something in one tool? Deletion applies to the shared store, so it is gone for both tools. That is the point of one memory, but it also means you should treat deletes as global. Most stores let you delete individual memories without wiping the account.