- 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.
- The AIVM plugin path is two commands after a free key mint; the MCP path is one JSON block and works for any MCP memory server.
- 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.
To give Claude Code persistent memory, connect it to an external memory store. The deepest path is a lifecycle plugin: install AIVM Brain's plugin with two commands and sessions are captured and recalled automatically. The generic path is an MCP memory server added to Claude Code's MCP config. Verify either with a fresh-session recall test.
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.
Setup for AIVM Brain's plugin: sign up free at brain.aivm.io, generate a key from the Connect screen (the dashboard hands you a personalized command), then run: claude plugin marketplace add AIVMNetwork/aivm-integrations, then claude plugin install brain-memory@aivm, and restart Claude Code, because plugins load at startup. Every Claude Code session on that machine now syncs to your brain, in every terminal.
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's block looks like this: command npx, args ['-y', '@aivm/brain', 'serve'], env with AIVM_BRAIN_URL and your AIVM_AGENT_KEY. Add it with claude mcp add or paste it into your MCP config, restart, and Claude Code gains brain.search and brain.capture style tools. The same block works in Cursor, Codex, Hermes, or OpenClaw, which is the quiet advantage of the MCP path: one memory, every agent.
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.