How to Make Claude Code Remember Across Sessions

The problem every Claude Code user hits

You spend an hour walking Claude through your codebase. You explain the deploy script, the conventions, the ten "we don't do that here" rules. You ship something good.

Tomorrow morning you open a fresh session. Claude has no idea who you are, what you're building, or that you've already had this exact conversation eleven times.

This isn't a Claude problem specifically — it's how chat models work. Each session starts with a blank slate. The only memory Claude has is whatever you (or your tooling) pastes back into the prompt.

If you're using Claude Code for real work — not just one-shot scripts — you've felt this. The pattern is always the same:

1. Hour 1 of the day: re-establish context.
2. Hour 2: do real work.
3. Tomorrow: hour 1 of context re-establishment again.

That's a 50% tax on every working day. It's also the reason most teams quietly bounce off Claude Code after a few weeks of trying.

This post walks through three patterns developers actually use to make Claude Code remember across sessions — ranked by how much engineering they require.

Pattern 1: The CLAUDE.md file (free, manual, brittle)

Claude Code already reads a CLAUDE.md file at the root of your project, plus a global one at ~/.claude/CLAUDE.md. Anything in those files lands in the system prompt for every session.

What it's good for: stable rules. "Use Bun, not npm. TypeScript needs explicit return types. Never commit to main."

What it's bad at: anything that grows or changes. Decisions you made yesterday. Bugs you debugged last week. The seventeen reasons you settled on a particular architecture.

The honest failure mode: most teams' CLAUDE.md slowly accumulates contradictions. "Use Postgres" lives at line 12; "We migrated to SQLite for the local dev path" lives at line 87. Claude reads both, picks one at random, and gives you advice that contradicts what you decided two weeks ago.

You can manually curate the file. Nobody actually does this past week three.

Verdict: ship a CLAUDE.mdwith your hard rules. Don't pretend it's memory.

Pattern 2: Roll your own with a project DB (mid-effort, hard to get right)

A common second move: write your own memory layer. Stand up a Postgres table, store facts as you go, recall them at the start of each session with a vector search.

People reach for this because the surface looks small: store a row, retrieve a row. In practice, three problems eat the next month of your life:

1. What's worth remembering?If you store every chat message, you'll have 50,000 rows in two weeks and recall will be noise. If you only store "important" things, you need a way to decide what's important — which means another model call per turn, which gets expensive fast.
2. How do you recall?Pure vector search returns "topically similar" chunks, not "factually relevant" ones. Your agent asks "what database are we using?" and gets back six chunks about database performance from a tutorial you read in March.
3. What happens when facts change? You said "we use Postgres" in February. You said "we migrated to SQLite"in April. Your DB now has both. Your agent will quote whichever one's embedding happens to win the cosine similarity battle on that particular query.

People underestimate problem #3 the most. Memory without contradiction handling is worse than no memory — it gives confidently wrong answers.

Real teams who go this route end up rebuilding the same three things: a dedup layer, a graph for entity recall, and a contradiction resolver. That's three months of work for a side-project of the actual product you're trying to build.

Verdict: worth it if memory is the product. Not worth it if you just want Claude to remember.

Pattern 3: An MCP-native memory layer (60 seconds to install)

The Model Context Protocol — MCP — lets Claude call external tools by name. You install a memory server once; from then on, Claude has access to recall(query) and remember(fact) as native tools, the same way it has access to read_file or bash.

The model itself decides when to call them. You don't have to think about prompt engineering or context windows. You don't paste anything. Claude asks "have I been told something about this codebase already?" before answering, and the answer comes from a persistent store that survives session restarts.

That's the shape. There are several MCP memory servers in the wild — open-source ones you self-host, hosted ones you point at. The decision matrix is the same as any infra:

• Self-host: your data stays on your machine, you maintain it.
• Hosted: no ops, you trust the vendor's deletion model.

What to look for, whichever path you pick:

1. Knowledge graph, not just vectors.Vector-only memory hits the same recall-noise wall as pattern #2. A graph layer lets the recall walk relationships ("the deploy script for the API service") instead of just guessing from cosine similarity.
2. Conflict resolution.When the system detects a fact that contradicts a stored one, it should resolve — not store both. Otherwise you re-create pattern #2's worst failure.
3. Browsable wiki pages, not opaque storage. You want to be able to seewhat the memory layer thinks it knows. The good ones auto-generate markdown wiki pages for every entity (with backlinks, aliases, the works), so you can read your agent's mental model like a normal doc site.
4. Sub-second recall. If recall takes seven seconds, the agent will quietly start ignoring it. Production memory layers hit sub-second.
5. A real deletion model.GDPR-grade hard-delete, not just "soft archive." This matters the day you wish it had mattered three months ago.

The 60-second install: most MCP memory servers ship as an npm package or a single config block in your ~/.claude/claude_desktop_config.json (or .mcp.json for Claude Code). Run one command, restart Claude, done.

What changes once you have it

Three things happen the first week:

What to actually do today

If you're a heavy Claude Code user:

1. Pick a memory layer.Self-host if you like running infra, hosted if you don't. Either is fine for evaluation — what matters is that it ships a knowledge graph and a contradiction resolver, not just vector search.
2. Install the MCP server. One config block, one restart.
3. Use Claude for a week without thinking about it. Don't try to "load" the memory; just let Claude remember as you work. The recall side is automatic.
4. At day 7, audit.Open the memory layer's wiki view. Read what it thinks it knows about your codebase. If it's accurate, you've got it. If it's noisy, the memory layer isn't filtering at ingest — pick a different one.

The bar is low. It just has to be better than re-explaining your codebase every morning.

Where Ricord fits

We built Ricord because we hit pattern #2 ourselves, lost a month, and decided the world needed pattern #3 to actually exist. Ricord is an MCP-native memory layer with a knowledge graph, auto-generated wiki pages for every entity, and automatic conflict resolution.

If you want to install it right now:

bun add -g ricord
ricord login
ricord install   # auto-detects Claude Code, Claude Desktop, Codex, Cursor

That's the 60-second install. Restart Claude, ask it to remember something, ask again tomorrow.

If you want to evaluate other options first, the patterns above hold — the bar to clear is real, but the ecosystem is finally good enough that you shouldn't be re-explaining your codebase every morning in 2026.