Persistent memory for Claude Code across sessions — the MCP options compared
CLAUDE.md, auto memory, Anthropic's reference memory server, hosted layers and local MCP servers compared: what each keeps, where it lives, what's missing.
"How do I give Claude Code a memory that survives the session?" has at least five honest answers now, and they are not interchangeable. Some are built in, some are MCP servers you add, and they differ on the things that matter: what gets captured, who decides what's worth keeping, where the data lives, and whether anything leaves your machine. Here is the landscape as of this writing, with the trade-offs stated plainly, including ours.
1. Built in: CLAUDE.md and auto memory
The Claude Code CLI ships two memory mechanisms, and they do different jobs.
CLAUDE.md is a markdown file of standing instructions. It can live at project level, in your home directory for every project, or as a gitignored local copy, and every file found from the working directory upwards is loaded into context at the start of a session. You write it, or /init drafts a first version. It is excellent for the things that never change: how to run the tests, the style rules, what not to touch. It is a brief, not a record. Nothing lands in it unless someone types it.
Auto memory is newer and automatic. In local sessions it is on by default: the agent writes notes it judges worth keeping — about you, your feedback, the project and references — into a per-repository folder under your home directory, and the first 200 lines of its index are loaded into every conversation, with topic files read on demand. It skips anything the codebase or your CLAUDE.md already says. Two properties to know: it is machine-local, so it doesn't follow you to another computer or cloud environment, and it is Claude-only, so Codex or another MCP client can't read it.
Together they cover the basics well. The gap is resolution. Both hold what someone, human or model, decided in advance was worth writing down. The exact command that worked yesterday, the test that started failing after a specific edit, the approach you already tried and abandoned — those live in the transcript and are compacted into a summary as the session grows.
2. Anthropic's reference memory server
The Model Context Protocol project publishes a reference memory server, @modelcontextprotocol/server-memory. It keeps a knowledge graph of entities, relations and observations in a JSON file whose path you configure, and exposes tools to create, search and read them. Because it speaks MCP, any client can use it, and it is a clean way to learn the pattern.
It is also entirely explicit. Nothing is stored unless the agent decides to call a tool, and nothing is recalled unless it decides to look. There is no record of what happened in a session, only what the model chose to write down about it.
3. Hosted memory layers
Several vendors sell memory as a service: a cloud store with an MCP server in front of it, so the Claude Code CLI, Codex and others share one memory. The upside is real — cross-tool, cross-machine, no files to manage. The cost is that your context leaves your machine: the decisions, the architecture notes, the unreleased plans all live in someone else's database under their terms and retention. For a team that already keeps its code in the cloud this may be acceptable. For a lot of developers, and most companies' security teams, it is the deal-breaker.
4. Community local servers
Between those sit a growing set of open-source servers that keep memory on your machine. Two patterns dominate. Some store notes in a folder inside the repo and expose them over MCP. Others register Claude Code CLI hooks on prompt submit and on stop, saving each exchange and injecting matches into the next prompt. Both keep your data local, which is the right instinct. Quality varies: many store flat text and retrieve by keyword, so recall gets noisier as the store grows, and maintenance depends on one author's weekend.
5. Verbative Memory
Verbative Memory is our answer, so weigh this section accordingly. It is built on one design choice: capture completely, select only at recall.
- Automatic capture and injection. Installing registers hooks for the Claude Code CLI and Codex. After every turn it captures what mattered; before every prompt it injects the handful of memories that are relevant. No tool calls, no "remember this", though the full toolset is there over MCP when you want to query or correct the record deliberately.
- Two layers, nothing dropped on a hunch. A lossless ledger records every command, edit and test result as replayable facts. On top of it an on-device model distills decisions, conventions and dead ends into typed memories, deduped and superseded as they change.
- Selective recall. Semantic search plus a reranker pull only the few facts that matter into each prompt, interleaved with the exact ledger events around them.
- Files in your repo. Human-readable, diffable, git-trackable if you choose, deletable in one move. No vendor database, no upload.
- Any MCP client can call the tools; automatic capture is for the Claude Code CLI and Codex.
- Measured, not asserted. Recall quality runs against public memory benchmarks through an open reproduction harness at github.com/verbative/verbative-benchmarks, which you can run yourself.
The engine itself is closed; the data layer is plain files you can inspect. Memory is part of the Advanced plan, and the pricing page has the details.
Side by side
| Option | Captures automatically | Where it lives | Shared across tools | Leaves your machine |
|---|---|---|---|---|
| CLAUDE.md | No, you write it | Your repo or home folder | Claude Code CLI only | No |
| Auto memory | Yes, what Claude judges worth keeping | Per-repo folder in your home directory | Claude Code CLI only | No |
| Reference memory server | No, explicit tool calls | A JSON file you configure | Any MCP client | No |
| Hosted memory layers | Varies by vendor | The vendor's cloud | Any MCP client | Yes |
| Community local servers | Some, via hooks | Repo folder or local store | Any MCP client | No |
| Verbative Memory | Yes, every turn, lossless ledger plus distilled facts | Readable files inside your repo | Hooks for Claude Code CLI and Codex, tools for any client | No |
Which one?
- You want standing instructions and nothing else: CLAUDE.md does that, and auto memory adds notes for free.
- You're learning MCP or need a shared graph you control: the reference server.
- Cross-tool memory and the cloud is fine with you: a hosted layer.
- Local, and you don't mind maintaining it: a community server.
- Local, automatic, specific and shared between the Claude Code CLI and Codex: Verbative Memory. How it works →
Frequently asked
Does Claude Code have memory across sessions?
Yes, two kinds. CLAUDE.md holds instructions you write, loaded at the start of every session. Auto memory, on by default in local sessions, lets the agent save notes it judges worth keeping into a per-repository folder and loads the first part of that index into each conversation.
Where does Claude Code store its auto memory?
In a memory folder per repository under your home directory, in the Claude projects directory. It is local to that machine and not shared with other tools or cloud environments. The /memory command shows the exact locations.
What is an MCP memory server?
A server that speaks the Model Context Protocol and exposes memory tools such as store, search and recall to any compatible client. Anthropic publishes a reference one that keeps a knowledge graph in a JSON file; hosted vendors and community projects offer others.
Is my memory shared between Claude Code and Codex?
The built-in CLAUDE.md and auto memory are Claude-only. MCP memory servers can serve any client. Verbative Memory captures automatically for both the Claude Code CLI and Codex through hooks and exposes its tools to any MCP client, from one set of files in your repo.
Does any of this send my code to the cloud?
Hosted memory layers do by design. CLAUDE.md, auto memory, the reference server and most community servers keep data on your machine. Verbative Memory runs its models and keeps its files on your machine, and nothing is uploaded.