Is there an MCP memory server that works with Claude Code, Cursor and Codex at the same time? is a question about whether one memory store can serve several AI coding tools at once. In practice, it comes down to three things: all three clients connect to the same server, they read and write the same records, and what one tool learns shows up in the others without you copying anything. The short answer is yes. Claude Code, Cursor and Codex all support the Model Context Protocol (MCP), so any MCP memory server can technically connect to all three. Whether that server gives you shared memory is a separate question, and it's where most setups break down.
At Open Agentic Brain & Memory (OpenAB), we built a free, open-source (Apache-2.0), self-hosted memory layer because we kept running into that gap. We'd decide something in Claude Code on Monday, open Cursor on Tuesday, and have to explain the whole project again. This guide covers what "works with all three" really means, compares the main kinds of memory servers, and is honest about where OpenAB fits and where it doesn't.
Why "it supports MCP" isn't enough
Every AI coding session starts from zero. The model doesn't remember that you dropped Redis for SQLite last week, that the team always uses pnpm, or that the flaky test in the payments module was a timezone bug you already fixed. Each tool also keeps whatever memory it has to itself. A rule saved in one editor's settings means nothing to the agent in your terminal.
MCP fixes the connection problem: one server, many clients. It doesn't fix the memory problem by itself. A memory server can connect to Claude Code, Cursor and Codex and still let you down in a few ways:
Nothing gets written. If the server only stores what the model decides to save, many sessions end with nothing saved at all.
Nothing gets read at the start. If memory only arrives when the model calls a recall tool, the agent often starts work before it checks what it already knows.
Everything gets read. Some setups paste a whole notes file into every chat. That burns tokens and pushes you into Claude, Cursor or Codex usage limits sooner.
Memory stays on one machine. Your laptop and desktop each learn different things and never share them.
Three levels of cross-tool compatibility
"Works with all three tools" can mean three different things. Before you pick a server, check which level it actually reaches.
Level 1: Connects
The server can be registered as an MCP server in Claude Code, Cursor and Codex, and each client can call its tools. Nearly every MCP memory server gets this far, because it's just a property of the protocol.
Level 2: Shares
All three clients read and write the same store, so a memory written from Claude Code can be recalled from Cursor. That requires one shared backing store, not a separate file per client, and it must handle several clients writing to it safely.
Level 3: Briefs
Each tool gets relevant context automatically when a session starts, before the model has to think of asking for it. This usually needs a start-up hook or an instruction file on top of the MCP tools. It's also the level that saves the most re-explaining, and the most tokens.
OpenAB is built for Level 3. It captures decisions, fixes and preferences from coding sessions, distills and ranks them, and injects a briefing capped at 2,000 tokens when a session starts. The tools can still recall on demand over MCP.
Compatibility matrix: the main types of MCP memory servers in 2026
Instead of grading individual projects, which change every few weeks, here's how the main kinds of memory setups behave across Claude Code, Cursor and Codex. Use it to sort any server you're considering.
1. Tool-native memory (rules files, built-in memories)
Connects to all three: no. Each tool keeps its own format and location.
Shared store: no. What Cursor knows stays in Cursor.
Session-start briefing: yes, but only inside that one tool.
Cross-machine: only if you sync the files yourself.
Best for: someone who sticks with a single tool.
2. Simple local MCP memory servers (a JSON file or knowledge graph)
Connects to all three: yes.
Shared store: yes, if every client points at the same file path.
Session-start briefing: usually no. Memory is only read when the model calls a tool.
Capture: manual. The model has to decide to save things.
Cross-machine: no, unless you sync the file yourself.
Best for: experiments and small personal setups.
3. Hosted memory APIs behind an MCP wrapper
Connects to all three: yes.
Shared store: yes, on the vendor's server.
Session-start briefing: depends on the vendor.
Cross-machine: yes, through the vendor.
Trade-off: you need an account, and your project decisions live on someone else's infrastructure.
Best for: teams that are fine with a third party holding their data.
4. Single-tool memory plugins
Connects to all three: sometimes, but they're designed around one client's hooks.
Shared store: often yes locally, but capture and briefing may only work in the main tool.
Session-start briefing: strong in the main tool, weak or missing elsewhere.
Best for: heavy users of one tool who occasionally open another.
5. Self-hosted, cross-tool memory layer (OpenAB)
Connects: Claude Code, Cursor, Codex and Antigravity, plus Kilo Code in beta.
Shared store: one local SQLite database used by every tool.
Session-start briefing: yes. A start-up hook injects at most 2,000 tokens in 84 ms (p50).
On-demand recall: MCP tools brain_recall, brain_remember, brain_context and load-my-brain. Recall over 10,000 memories takes 28 ms (p50).
Cross-machine: yes. Memory syncs as an age-encrypted blob stored as a Release asset in your own private GitHub repo.
Account required: none. We don't run a server.
Setting up one memory server across Claude Code, Cursor and Codex
The steps below apply to any MCP memory server you want shared across the three clients. The key rule: every client must point at the same server and the same storage location.
Claude Code. Register the server with Claude Code's MCP configuration, either through the CLI or a project or user-level MCP config. Use user scope if you want memory available in every repo, not just one.
Cursor. Add the same server to Cursor's MCP settings. A global config makes it available in every workspace. Make sure the command and arguments match what you gave Claude Code.
Codex. Add the server to the MCP servers section of Codex's configuration file, again with the same command so it opens the same store.
Instruction files. Tell each agent the memory exists. Without a line in CLAUDE.md, AGENTS.md or GEMINI.md, models often skip recall tools altogether.
Test it. Save a fact in one tool, such as "we use pnpm, never npm", then open another tool and ask it how to install dependencies. If it says pnpm without you mentioning it, the setup is shared.
OpenAB handles steps 4 and 5 for you. It writes a map of up to 20 of your projects into the global CLAUDE.md, AGENTS.md and GEMINI.md, and its start-up hook delivers the briefing so the agent doesn't have to remember to ask. The install steps for each client are in the GitHub repo, rohithhn/Open-Agentic-Brain-and-Memory.
What happens when two tools run at the same time
"Simultaneously" in the question matters. Plenty of developers run Claude Code in a terminal while Cursor is open on the same repo, with Codex working on a side task. Usually each MCP client starts its own server process, so you can have three processes touching one store.
That's where file-based memory servers break. Two processes rewriting the same JSON file can overwrite each other's changes. A database built for concurrent access is a much safer base, which is one reason OpenAB stores memory in local SQLite rather than loose files.
Running at the same time also raises a question of scope. If Cursor is open on your API repo and Claude Code is open on your frontend, each one should see its own project's history first. OpenAB tags every memory by project, which it finds by walking up to the nearest .git folder. Opening a folder brings that repo's history to the top, but projects aren't walled off. Recall can search one project or all of them, so a fix you found in one service can still turn up when the same bug appears in another.
Why token budget is the real compatibility test
A memory server that "works" in all three tools but pastes thousands of lines into every session isn't really helping. You pay for those tokens in every chat, in every tool, and hit your limits sooner.
We designed OpenAB around a fixed budget. Each tool gets a briefing under 2,000 tokens. For a store of 10,000 memories, loading context takes 1,325 tokens instead of the 1,131,367 it would take to load everything. On the LoCoMo benchmark, OpenAB keeps 97% of the full-conversation score while reading 18% of the tokens. Fewer tokens per session means you run into Claude, Cursor and Codex limits later, and the model spends its context window on your code instead of on history it doesn't need.
Ranking is what makes the budget work. OpenAB uses hybrid search (keywords plus meaning) and outcome scores, so memories that helped before rank higher. If you want proof on your own data rather than ours, brain eval scores recall against your own history.
Where OpenAB fits, and where it doesn't
OpenAB is the privacy-first, owner-held alternative to hosted memory APIs. There's no account and no vendor server. Memory lives in SQLite on your machine. When it syncs, it's age-encrypted, the key stays only in your OS Keychain, and the encrypted blob is stored as a Release asset on your private GitHub repo. If that repo or your token leaks, nothing in it is readable. At start-up, OpenAB merges in what your other laptops learned, so you get the same briefing on every machine.
You can also see everything it keeps. A local control panel lets you read, edit, pin or delete every memory. You can seed it from past AI work or start fresh. You can see the full picture of how capture, briefing and sync fit together on the Open Agentic Brain & Memory project site.
Where it may not fit:
You want a managed service. OpenAB is self-hosted. If you'd rather not run anything locally, a hosted API is simpler.
You need memory shared across a whole team. OpenAB is built around one person's memory across their own tools and machines, synced through their own private repo.
Your tool isn't on the list. Today that's Claude Code, Cursor, Codex and Antigravity, with Kilo Code in beta.
FAQ
Is there an MCP memory server that works with Claude Code, Cursor and Codex at the same time?
Yes. Any MCP server can connect to all three. For memory that's truly shared, meaning one store, automatic briefings and cross-machine sync, you need a cross-tool memory layer like OpenAB, which supports all three plus Antigravity and Kilo Code (beta).
Do I need a separate memory file for each tool?
No, and you shouldn't use one. Separate files are exactly why each tool forgets what the others learned. Point every client at a single store.
Will a memory server slow down session start?
It depends on the server. OpenAB's start-up hook injects its briefing in 84 ms (p50), and on-demand recall over 10,000 memories takes 28 ms (p50).
Does my memory leave my machine?
With OpenAB, only as an age-encrypted blob in your own private GitHub repo, and the key never leaves your OS Keychain. We don't run any servers.
How does it know which project I'm in?
It walks up from your current folder to the nearest .git and tags memories with that project. Recall can stay inside the project or search across all of them.
Can I fix a memory that's wrong?
Yes. The local control panel lets you edit, pin or delete any memory, so an outdated decision doesn't keep getting injected.
Conclusion
Connecting one MCP memory server to Claude Code, Cursor and Codex is easy, because the protocol takes care of it. The hard part is making the three tools share what they learn, brief each session without wasting tokens, and stay in sync across machines without giving your data to someone else. That's what we built Open Agentic Brain & Memory to do: tell one tool, and every tool knows.
OpenAB is free and Apache-2.0, built by Rohith, Chandan and Sushmita. Our blog has more detail in its guides on AI memory layers, context engineering, long context vs RAG vs memory, agent hooks and self-hosted memory privacy, and the source is in the rohithhn/Open-Agentic-Brain-and-Memory repo on GitHub.
Top comments (0)