How to give Claude Code memory between sessions
You close the window and it is gone. Tomorrow you explain the architecture again, and the reason you rejected the obvious approach, and which part of the codebase is a minefield. Next week you explain it to Cursor instead, from scratch, because that is a different tool with a different nothing.
There are three real answers to this and they are not alternatives - they solve different problems. Most of the frustration comes from using one where you needed another.
1. --continue and --resume: the same conversation, later
claude --continue picks up the most recent conversation in the current
directory. claude --resume lets you choose from a list.
What it persists: the literal conversation - every message, the full context.
Where it stops: it is one thread. It does not help a second project, a second tool, or a second person, and a long-running thread eventually gets compacted anyway. It is "reopen the tab", not memory.
Use it when you are mid-task and coming back tomorrow.
2. CLAUDE.md: instructions you maintain
A file in the repository root, loaded into context at the start of every session. Conventions, commands, architecture notes, the things you would tell a new hire on day one.
What it persists: whatever you typed into it, exactly, forever.
Where it stops: three places, and they are worth being honest about because this is the option most people should try first.
- It goes stale silently. Updating it is a chore, so it does not get done, and a stale instruction is worse than a missing one because the agent follows it confidently.
- It holds instructions, not history. "Use Postgres" is a rule. "We chose Postgres over DynamoDB in March because we needed row-level security, and here is what we tried first" is a decision with a reason, and a file that accumulates those turns into an unreadable changelog nobody reads.
- It is per-repository. A decision that spans two repos, or a client relationship that spans none, has nowhere to live.
Use it when your project is small, stable, and mostly one person's. If that describes you, stop here. A hand-edited file has no failure modes and costs nothing, and everything below is overhead you do not need.
3. An MCP memory server: state that accumulates on its own
MCP lets Claude Code talk to an external server. A memory server exposes tools the agent can call to read and write what it knows, and the memory lives outside any one conversation - so Cursor and ChatGPT can read the same one.
What it persists: depends entirely on the server, and this is where they differ most.
The two kinds, and why the difference matters
Most memory servers are personal: the memory is scoped to you and follows
you between projects. It learns your preferences and your habits. Mem0 is the
best-known of these, and its scope model - user_id / agent_id / run_id / app_id - tells you exactly what it is built around.
A few are project-scoped: the memory belongs to the engagement, and everyone working on it shares one. A colleague who joins on Thursday reads what was decided on Monday without anyone writing a handover doc.
Which you want depends on what keeps going stale. If your agent keeps forgetting you, personal memory is the fix. If it keeps forgetting the work - what was settled, what is blocked, what you already tried and dropped - that belongs to the project, and putting it in a user profile means the next person starts from zero.
The part that decides whether any of it works
Almost every memory product works like this: the agent is told it may call
add_memory when something matters.
That is advice, and a model under load ignores advice. It is the reason most memory graphs are much emptier than their owners assume - not because the storage failed, but because nothing ever asked it to store anything. If you try one of these, the honest test is to use it for a week and then go and look at what is actually in it.
The alternative is a hook. Claude Code fires an event when a turn ends, and a server can decide for itself whether anything durable happened, with no reliance on the agent choosing to act. Kika works this way, and it is the single design decision that matters most.
Which one you need
| What keeps hurting | What fixes it |
|---|---|
| Coming back to the same task tomorrow | claude --continue |
| Re-typing the same conventions and commands | CLAUDE.md |
| Your agent forgetting you across projects | A personal memory server |
| Re-explaining the same decisions to a second tool | A project-scoped memory server |
| A colleague starting from nothing | A project-scoped memory server |
They compose. CLAUDE.md for rules, a memory server for what accumulated - the
file says how we do things here, the memory says what we decided and why.
Setting up Kika, if that is the row you landed on
claude plugin marketplace add usekika/kika-plugin
claude plugin install kika@kika
Then /mcp, choose kika, and approve in the browser. The plugin carries both
halves - the MCP tools and the end-of-turn hook - so there is nothing to clone
and no second credential.
From there it works without being asked. Each project gets its own memory, bound to the git remote so a teammate's checkout lands in the same one rather than forking a second graph. Every fact it writes shows where it came from and can be removed in one click.