How to share project context between Claude Code and Codex

The way people actually work with coding agents is plural. One for large refactors, another for quick fixes, a third inside the editor, sometimes a web client for planning. Each has strengths, and switching between them is normal.

What's not normal, and what nobody would accept from human colleagues, is that none of them can tell each other anything. Claude Code spends an afternoon establishing why an approach doesn't work. Codex, the next morning, proposes it.

Why nothing crosses

It's worth seeing exactly how complete the separation is.

The last row is the whole answer, and it's the only row that can be. Anything a tool owns is a tool's memory. Only something outside both can be the project's.

(Yes, you can maintain CLAUDE.md and AGENTS.md as copies of each other. People do. It works until they drift, which is roughly two weeks, and it inherits every size limit of an instruction file anyway.)

The setup

One workspace, two clients pointed at it.

Create the workspace (free, no card), then:

Claude Code

claude mcp add --transport http knownbase https://knownbase.dev/mcp

Codex

{
  "mcpServers": {
    "knownbase": {
      "url": "https://knownbase.dev/mcp"
    }
  }
}

Both authenticate against the same workspace — OAuth opens a browser, or use the same API key in both if your client needs static config. Details: Claude Code setup, Codex setup. Cursor and ChatGPT connect to the identical endpoint if you want them in the loop too.

Both need the same instruction

Each tool reads its own instruction file, so the rule has to be written twice. Same words, two files — and this stays short, unlike the knowledge itself, so keeping the two in sync is genuinely easy.

In CLAUDE.md and AGENTS.md:

## Project memory

This project has shared persistent memory via the `knownbase` MCP
server, under project "<your-project>". Other agents write to it too.

Before starting a task, `search_notes` for decisions, constraints and
prior debugging findings about the area you're touching. Assume
another agent may have worked on this since you last did.

When you learn something durable, `upsert_note` it: a decision and
its reasoning, a non-obvious root cause, an environment constraint,
an approach that was tried and rejected, or a handoff if you're
stopping mid-task.

Attribute significant findings to the agent that made them, so a
later reader knows where a claim came from.

The “assume another agent may have worked on this” line does real work. Without it, an agent treats memory as its own notes; with it, it treats memory as a shared record it should check.

What this looks like in practice

The note itself:

upsert_note({
  project: "reporting",
  title: "Export job cannot be parallelised — provider rate limit is per account",
  tags: ["constraint", "rejected-approach", "exports"],
  status: "active",
  body: "Nightly export is bounded by the provider's rate limit, not by\n" +
        "our processing. The limit is per ACCOUNT, so concurrent requests\n" +
        "trip 429 regardless of connection count.\n" +
        "Tried and rejected: worker pool, connection-per-shard.\n" +
        "What worked: maximum page size, serial loop.\n" +
        "Found by Claude Code, 2026-08-10. src/exports/nightly.js:140."
})

That note is worth an afternoon, and it's worth it every time any agent is asked to make the export faster.

Handoffs between different agents

The other high-value case is stopping mid-task in one tool and continuing in another. A handoff note is what makes that work: goal, what's done, what's in progress, decisions taken, dead ends, the single next step, and pointers to the exact files.

Written to shared memory rather than pasted into a chat, it doesn't matter which tool picks it up. That's a meaningfully different workflow from “finish what you started in the tool you started it in”.

Why not just use one agent?

A fair question, and sometimes the right answer. But two things push the other way. Different agents genuinely are better at different things, and the mix changes as they do. And if anyone else works on the codebase, you don't get to standardise their choice anyway — a shared store handles teammates for the same reason it handles tools.

The deeper point: memory that belongs to a tool is a lock-in you didn't choose. Memory that belongs to the project moves with the project.

Related reading

• Persistent memory for Claude Code
• Persistent memory for Codex
• Writing a handoff the next agent can use
• MCP memory servers explained

FAQ

Can Claude Code and Codex share memory directly?

No. They're separate tools with separate sessions, separate instruction files and separate built-in memory. Sharing requires a store outside both, which in practice means an MCP server they can both reach.

Do I have to duplicate CLAUDE.md and AGENTS.md?

You need the memory rule in both, since each tool reads only its own file. That's a dozen lines and it doesn't grow. What you should not duplicate is the knowledge itself — that's what the shared store is for, and copies of it will drift.

Will one agent overwrite another's notes?

Not by accident. Updates are partial, so writing one field leaves the rest alone, and every edit is snapshotted as a revision, so you can see what changed and restore it. For stricter safety an agent can pass the version it expects and get a conflict error instead of overwriting.

Does this work with Cursor and ChatGPT too?

Yes — same endpoint, same workspace. Any MCP client that supports remote servers joins the same shared memory.