Give Claude Code Persistent Memory, Properly
Contents
Claude Code memory
The setup, and the test that proves it
To give Claude Code persistent memory, connect it to an external memory store. For AIVM Brain, follow the current in-app connection setup for your workspace and client. The generic path is an MCP memory server added to Claude Code's MCP config. Verify either with a fresh-session recall test.
- Claude Code's built-ins (CLAUDE.md, auto memory, session summaries) help, but they are per-machine, per-user, and not shared or governed.
- Persistent memory means an external store: either a plugin hooked into Claude Code's lifecycle, or an MCP memory server Claude Code queries as a tool.
- AIVM Brain provides current connection instructions in your workspace; follow the setup for your chosen client and access scope.
- Prove it with the fresh-session recall test: store a fact, end the session, reopen, ask. Recall from a cold start is the only test that counts.
- For teams, per-person and per-agent permissions plus an access log are what make shared Claude Code memory safe.
What Claude Code remembers on its own
Out of the box, Claude Code has three context mechanisms: CLAUDE.md files you write by hand, an auto memory directory where it keeps notes about your projects, and summaries it can pull from past sessions. They are useful, and worth setting up well.
Their shared limits are structural: they live on one machine, serve one user, and nothing governs or shares them. The decision your teammate's Claude Code learned yesterday is not in your CLAUDE.md. Your own auto memory does not follow you to the server you SSH into. And nothing records what was read. Persistent memory, in the sense that matters, means an external store with an API.
Path A: the lifecycle plugin (deepest integration)
A plugin hooks Claude Code's session lifecycle, so memory works without you thinking about it: durable facts get captured as you work, and recalled context is injected when sessions start. Lifecycle hooks are what turn a database you occasionally query into a memory you never think about.
For AIVM Brain, log in to your workspace and follow the current in-app setup for Claude Code. New visitors can join the waitlist and confirm their work email. The workspace instructions are the reference for connecting a client and assigning its access.
Path B: an MCP memory server (works for any store)
An MCP memory server is a small server exposing store-and-recall tools that Claude Code can call like any other tool. The ecosystem has several (Mem0's server and various open-source memory keepers among them, as of mid-2026); they differ in what they store and whether anything governs access. The wiring is the same for all of them: a server block in Claude Code's MCP configuration.
AIVM Brain provides agent connection instructions inside your workspace. Use those instructions for your client, then test retrieval against an approved source. Keeping one governed store behind compatible MCP clients lets your tools retrieve shared project knowledge without copying every fact into a separate context file.
The recall test (do not skip this)
Whichever path you chose, prove it. In a session, tell Claude Code a durable, checkable fact: 'remember: our staging DB is Neon, the branch naming rule is feat/*'. End the session fully so it syncs. Open a new terminal, start fresh, and ask 'what is our staging DB?'
A correct answer from a cold start means you have persistent memory. A wrong or empty answer means one of the usual three: the agent was not restarted after install, the key never landed in the key file or env, or you asked before the first sync completed. Fix, retest. Memory you have not tested is memory you do not have.
What to store, and the team question
Store decisions with reasons, project facts, fixes that cost you an hour, preferences. Do not store secrets (that is what secret managers are for), and do not dump transcripts; distilled facts retrieve better than raw logs.
Solo, that is the whole story. On a team, the questions change: who may recall the compensation discussion? Which agent read the incident doc, and when? This is where governance becomes the feature: per-member and per-agent keys, permission-aware retrieval, field-level redaction, and a tamper-evident log of every access. That layer is AIVM Brain's actual job, and it is why we built the memory on top of it rather than the other way round. The product page for this is brain for Claude Code.
Frequently asked questions
Does Claude Code have persistent memory built in?
Partially. CLAUDE.md, auto memory, and session summaries carry context forward on one machine for one user. For memory that survives machines, is shared with a team, or is governed and auditable, you connect an external store.
What is an MCP memory server?
A server that exposes memory tools (store, search, recall) over the Model Context Protocol. Claude Code calls it like any tool, so facts persist outside the session. AIVM Brain offers governed retrieval over MCP; follow the connection instructions in your workspace.
Plugin or MCP config: which should I pick for Claude Code?
The plugin, if you use Claude Code heavily: lifecycle hooks make capture and recall automatic. The MCP block is the universal path and is right when you want one config pattern across many agents.
Does this work across multiple machines?
Yes. The brain is a service, so any machine with your key syncs to the same memory. Key each machine once, and every Claude Code session on it participates.
Can my team share Claude Code memory safely?
Yes, with governance: each member and agent gets a scoped key, retrieval is permission-aware, sensitive fields can be redacted, and every access is logged. Without those, shared memory is an oversharing incident waiting to happen.
Is my code or data used for training?
No. You bring your own model key and nothing you store trains any model. Storage is per-tenant, and the access log is content-blind.
