Claude Code Persistent Memory Between Sessions: How to Set It Up

The short answer: Claude Code only keeps working context for the lifetime of a session. To get persistent memory between sessions, combine its built-in memory files with an external memory store: keep durable project facts in CLAUDE.md files, and connect an MCP memory server so decisions, progress, and conventions are saved once and recalled automatically at the start of every future session, on any machine.

What does Claude Code remember natively?

Within a single session, Claude Code remembers everything: the full conversation, the files it read, the commands it ran, and the conclusions you reached together. That is why long sessions feel so productive.

But that memory is scoped to the session. Close the terminal, start a new session tomorrow, or open the same project on a different machine, and the working context is gone. Claude Code does not automatically carry over what you decided, what failed, or where you left off. Every fresh session starts from zero unless you deliberately give it something to read.

What is the CLAUDE.md pattern, and how far does it go?

Claude Code automatically reads CLAUDE.md memory files at the start of a session — from the current directory, parent directories, and your home folder. This is the built-in answer to persistence, and it works well for one specific kind of knowledge: stable facts.

Good candidates for CLAUDE.md:

• The stack and how to run the project (build, test, and lint commands)
• Coding conventions the project follows
• Architecture notes that rarely change
• Hard rules, like "never commit directly to main"

Where it falls short: CLAUDE.md is static. It does not record what happened — the decision you made on Tuesday, the approach that failed on Wednesday, the half-finished refactor you need to resume on Thursday. Someone has to write and maintain it by hand, and it only travels with the machine or repo that holds the file. It is a briefing document, not a memory.

Where does session memory fall short across machines?

The gap gets painful the moment you work in more than one place. A new laptop, a second checkout of the repo, a cloud dev box: none of them know what your last session learned. Even on a single machine, the useful knowledge from a session — "we decided to drop the Redis cache because the invalidation logic was too fragile" — lives only in that session's transcript, which you will never re-read.

The result is a re-briefing tax. Every session starts with you re-explaining the codebase, the constraints, and the current plan. If you live in Claude Code daily, that tax compounds fast.

How do you give Claude Code persistent memory with an MCP memory server?

The pattern that closes the gap is an MCP memory server. Claude Code supports MCP servers, and a memory server exposes tools the agent can call to save and recall information. Instead of memory living in one session's transcript or one machine's files, it lives in a store the agent reads at the start of each session and writes to as work happens.

Set it up in five steps:

1. Pick a memory store. Options range from a local file-backed MCP memory server to a hosted service. Local keeps everything on your disk; hosted means the memory follows you to any machine with no files to sync.
2. Register it with Claude Code. Add the server to Claude Code's MCP configuration so its tools — save memory, recall memory, list, delete — are available in every session.
3. Write a session-start habit. Add a short instruction to your CLAUDE.md or project rules: at the start of each session, query the memory store for relevant context about the current task before doing anything else.
4. Write a session-end habit. Same place, second instruction: before wrapping up, save the durable outcomes — decisions made, approaches that failed, and where the work stands.
5. Test it with a fresh session. Close everything, open a new session, and ask what it knows about the project. If it briefs you correctly, the loop is working.

Steps 3 and 4 are what turn a memory store into actual persistent memory. The tools alone do nothing; the agent has to be told when to read and when to write.

What if you do not want to run memory infrastructure yourself?

If hosting and maintaining a memory server sounds like a second job, a hosted option removes it: Vilix AI exposes shared memory over MCP, so every Claude Code session — and every other connected tool — pulls from the same store with nothing to sync. The honest tradeoff is that it is cloud-only: if your setup requires everything to stay on your own machines, it is not the fit. (vilix.ai)

How do you keep persistent memory useful instead of noisy?

A memory store degrades into a junk drawer if everything gets saved. A few rules keep it sharp:

• Save decisions and outcomes, not play-by-plays. "Chose Postgres over SQLite for the queue table because of concurrent writers" beats a transcript of the whole debugging session.
• Save failures. The approaches that did not work are the most valuable memories — they stop future sessions from repeating them.
• Prune on a schedule. Once a month, delete or update entries that no longer reflect the project. Stale memory is worse than no memory, because the agent trusts it.
• Prefer semantic recall. A store with semantic search finds what you meant, not just exact keywords, so "the caching decision" surfaces even if you saved it under "Redis removal."