DEV Community

Abdeljabbar Elassali
Abdeljabbar Elassali

Posted on

One memory for Claude Code and Codex: stop copy-pasting context

One memory for Claude Code and Codex: stop copy-pasting context

You know the drill. You spend an hour in Claude Code getting the data model right, then you open Codex to wire up the backend and it asks you questions Claude Code already answered. So you paste the whole design doc into the new session. Then the next day you do it again, in the other direction. The copy-paste tax is real, and it compounds.

There is a cleaner way: give both tools one shared memory over MCP. Configure it once, and every session in either tool starts with the project's decisions, failed attempts, and open tasks already loaded. No more pasting.

The core idea in one paragraph

Claude Code and Codex each keep their conversations to themselves. A shared memory store sits outside both of them and exposes MCP tools both can call. Your agents save what matters at the end of a session and load what is relevant at the start of the next one. The tools stay exactly as they are; the memory becomes the common ground.

Wiring it up

Pick a memory store that speaks MCP. Then point both tools at the same one. In Claude Code, that means adding the server to your MCP config:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "<your-memory-mcp-server>"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

In Codex, add the equivalent MCP server entry in its config so it connects to the identical backend (same account, same API key, same database). This is the single most common failure mode: two tools pointed at two different stores is just two silos with extra steps. Verify both resolve to the same store before you go further.

Then build two habits into your workflow:

  1. Save on the way out. End of session, or at natural checkpoints: what was the goal, what did you decide, what did you try that failed, what is still open. If your setup auto-saves turns, even better; if not, make the last message of the session a deliberate save.
  2. Load on the way in. Start meaty sessions with an explicit pull: "check shared memory for this project before starting." Good retrieval is selective. It should return what is relevant to the current task, not dump the entire archive into context.

Smoke-test the loop: save a decision in Claude Code ("we switched the queue from Redis to Postgres"), open a fresh Codex session, and ask it what queue you are using. If it answers correctly without you pasting anything, the handoff works.

Decide what lives in the shared store

Shared memory is not a junk drawer. Put in the durable material: architecture decisions, API contracts, coding conventions, the task list, approaches that failed (so neither tool retries them), and reusable procedures you want every future session to follow.

Leave out the ephemeral: half-finished edits, scratch reasoning, credentials, and anything you would not want surfacing in every session for the next year. A decent filter: if the other tool would need it three weeks from now, it belongs in the shared store. If it only matters for the next ten minutes, it does not.

Dealing with two writers

Two tools writing to one store will eventually disagree. Claude Code records decision X on Monday; Codex records decision Y on Wednesday. Handle it with two rules:

  • Last write wins, and say it out loud. When a decision changes, state the change explicitly ("we dropped X, we are doing Y now") and save that statement. Recency-aware retrieval then surfaces the newest version to both tools, and you only ever correct things in one place.
  • Timestamp everything. When two entries genuinely conflict and neither is an update, keep both with their timestamps and sources so the current agent can reconcile them instead of silently picking one.

The failure mode to avoid is quiet divergence: both tools confident, both wrong about each other, no record of the disagreement anywhere.

Cloud vs. self-hosted

The only real decision is where the store lives. Self-hosted MCP memory servers keep everything on your machine: full control, zero subscription, but you own the setup and the backups. Cloud-hosted options flip that: nothing to run, memory follows you across machines and devices, but your data lives on someone else's infrastructure.

One cloud option is Vilix AI, a hosted memory store both tools reach over MCP, so the same memory is available in Claude Code, Codex, and anything else MCP-compatible you connect. The tradeoff is the cloud-only part: if your threat model or your preferences demand local-first, a self-hosted server is the better fit. Either way, the architecture is identical; only the hosting changes.

Why this beats the alternatives

The obvious alternatives are manual: a CONTEXT.md you maintain by hand, or pasting summaries between sessions. Both rot. The file goes stale the week you are busiest, which is exactly when you need it most. The paste workflow breaks the moment the context exceeds what you are willing to retype.

A shared store automates the boring part. The agent saves and loads as part of its normal operation, the record stays current because writing it costs one tool call instead of ten minutes of your attention, and the memory compounds: every session in either tool makes the next session in both tools smarter.

The payoff

Once the loop is running, switching tools stops feeling like starting over. Plan in Claude Code, build in Codex, review in whichever you like: the context travels with you instead of dying at the session boundary. Set aside thirty minutes to wire it up once, and the copy-paste tax is gone for good.

Top comments (0)