Levirge · blog

CLAUDE.md, auto memory or an MCP memory server: what each remembers, and who sees it

Claude Code already remembers. The useful question is who else gets to see what it learned - your next session, your other machine, your teammate, your other tools.

"Does Claude Code have memory?" has a short answer: yes, two kinds. The longer and more useful answer is about reach. Something Claude learned this morning - your next session might see it. Your laptop at home might not. Your teammate almost certainly won't. Codex never will.

This post goes layer by layer: what each one holds, who writes it, and who else can see it. Everything about Claude Code below is from Anthropic's memory docs, checked on 7 November 2026.

Layer 1: CLAUDE.md - instructions you write

CLAUDE.md files hold instructions and rules. You write them; Claude loads them at the start of every session. There are four scopes, and the scope decides who sees them:

Scope Where it lives Who sees it
Managed policy A system path set by IT, such as /etc/claude-code/CLAUDE.md on Linux Everyone in the organisation
User ~/.claude/CLAUDE.md Only you, in every project
Project ./CLAUDE.md or ./.claude/CLAUDE.md Your team, through source control
Local ./CLAUDE.local.md, gitignored Only you, in this project

Two details from the docs are worth knowing. They suggest keeping each file under 200 lines, because longer files cost context and reduce adherence. And Claude treats these files "as context, not enforced configuration" - if something must never happen, a hook enforces it, not a sentence.

The project CLAUDE.md is the only one your team shares, and it shares through git. That makes it the right home for conventions, and the wrong home for anything that changes every day.

Layer 2: auto memory - notes Claude writes

Auto memory is the opposite arrangement: Claude writes it, from your corrections and preferences. It lives under ~/.claude/projects/<project>/memory/, one directory per repository, shared across that repository's worktrees. The first 200 lines or 25 KB load into every session.

And then the sentence that matters for this post: "Auto memory is machine-local." Files "are not shared across machines or cloud environments."

So the fix Claude learned on your laptop stays on your laptop. Your desktop starts without it. Your teammate's Claude starts without it. A cloud session starts without it.

What neither layer covers

Put the two together and the gap is clear:

  • What an agent learns while it works - a cause found, a fix that worked, a decision made - lives in auto memory, on one machine.
  • What the team shares is what someone took the time to write into a committed CLAUDE.md.
  • Other tools see neither. Codex, Cursor and ChatGPT each keep their own memory.

For one person on one machine, that is often fine. For a team, or for anyone who moves between tools, it means re-explaining things that were already worked out.

Layer 3: an MCP memory server

An MCP memory server sits outside the tool. Any client that speaks MCP can read from it and write to it, which is what makes it shareable. The options differ a lot in where the memory lives:

  • The reference Knowledge Graph Memory Server (@modelcontextprotocol/server-memory) keeps a knowledge graph in a local JSONL file. It is simple and yours. Its README warns that the default location sits inside the server's own directory, where an update or a cleared npx cache can delete it - set MEMORY_FILE_PATH to a path you own. It is still one file on one machine.
  • Basic Memory is open source under AGPL-3.0, and also offers a hosted Teams workspace for sharing across people and their assistants.
  • Levirge Brain is ours, so read this as disclosure rather than a neutral pick. It is a hosted MCP server where a team shares one Vault per project, summaries cite the documents they came from, and Claude Code, Codex, Cursor and other clients read the same memory.

There are many more. Whichever you look at, ask the same five questions:

  1. Where is it stored? A file on one machine, or a service?
  2. Who can read it? Can you limit a token to one project, or make it read-only?
  3. Can you tell where a fact came from? A memory without sources is a rumour with good recall.
  4. What happens when a fact changes? Does the old version keep winning?
  5. Does the agent actually write to it? A memory only holds what gets captured - by a plugin, a hook or an instruction.

Which layer for what

  • Rules and conventions for the project → project CLAUDE.md, in git.
  • Your own preferences → ~/.claude/CLAUDE.md, or CLAUDE.local.md for one project.
  • Must never happen → a hook, not a sentence.
  • What Claude learns, for you, on this machine → auto memory. It is on by default in local sessions and costs you nothing.
  • What agents learn, for the team, across machines and tools → an MCP memory server.

The layers stack. A memory server doesn't replace CLAUDE.md; it holds the part CLAUDE.md was never meant to.

More on the shared layer: Shared memory for Claude Code, across sessions, machines and your team and One memory for Claude, ChatGPT, Codex and Cursor.

Get new posts by email

One email when a new post goes up. No pitch, no list swapping, unsubscribe in one click.

We use your address for post notifications only. See the privacy notice.

Check your inbox

Confirm the subscription from the email we just sent and you're on the list.