Why Claude Code forgets what you told it yesterday

Claude Code's session memory is by design. The fix is an external memory layer you run yourself, not a feature request to Anthropic.

What Claude Code keeps between sessions

Three things survive when you close the terminal. Your CLAUDE.md files (project scope in the repo, user scope at ~/.claude/CLAUDE.md, and enterprise scope for managed setups) get loaded into context at the start of every session. Auto memory notes written to ~/.claude/ from your corrections during prior runs also get pulled back in. That's it.

Everything else gets dropped. The actual conversation turns, the file reads, the tool outputs, the reasoning you watched happen: none of it persists. When you type claude tomorrow, the model starts from scratch with just the instruction files and whatever auto memory scraps it saved.

What this means in practice

If you spent 40 minutes yesterday explaining why a test was failing, and the fix required three rounds of clarification, that reasoning is gone. Claude Code rebuilds its view of your project from CLAUDE.md plus whatever you retype into the prompt. The correction you made at minute 38 is not coming back unless you or the auto memory system wrote it down.

Why this is by design

Context windows cost money and degrade quality past a certain fill rate. If Claude Code replayed every turn from every session, a six-month-old project would blow past the window in one message and the signal-to-noise ratio would drop off a cliff well before that. Stateless-per-session is the honest trade: fresh context every time, nothing stale, you decide what's worth re-injecting.

Anthropic built the auto memory hook as a compromise. User corrections that look rule-shaped get written to disk so the next session at least inherits the lessons, not the transcripts. That's a reasonable line to draw. It also happens to be a thin line when you're doing real work across many days.

The workarounds people try first

Most teams hit this wall and reach for the obvious tools.

• Pasting yesterday's summary into the prompt. Works for one or two sessions. Breaks the moment you have five active threads or you forget which summary matches which branch.
• Growing CLAUDE.md until it's 2,000 lines. The file is meant to be standing rules, not episodic memory. Past a few hundred lines the model starts treating it as background noise and the per-session token cost gets noticeable.
• Piping git log or diffs into the first message. Tells Claude what changed in the code. Tells it nothing about why, what you tried that failed, or what the user correction was.
• Screenshots and notes in a side doc. You end up maintaining a second brain manually. That's the job you were hoping to offload.

Each of these scales to about one developer on one project for about two weeks. Then the seams show.

Where an external memory layer helps

A few projects have taken different swings at this. They're not the same thing, and the choice between them depends on what you're trying to fix.

claude-mem

claude-mem (AGPL-3.0) runs a Bun daemon on port 37777, backed by SQLite, a Chroma vector store, and FTS5 full-text search. It compresses old session turns and re-injects them when they look relevant. If what you want is "my past conversations, searchable and hot-pluggable into the next session", this is the most direct answer.

mem0

mem0 (Apache 2.0) is a library, not a daemon. It uses an LLM to extract facts from conversation history and a vector index to retrieve them. You can self-host it or use their SaaS. It's more general-purpose than claude-mem: built for any LLM app, not just Claude Code.

Munin

Munin is what this site is. It's a local Rust binary that reads your ~/.claude/ and ~/.codex/ transcripts and turns them into a structured layer of observations, claims, and rules, each with freshness, stability, and confidence scores. Four commands: resume, nudge, promote, friction. No SaaS, no vector database, no retrieval-style "similar chunks" search. The point is correction loops: when you keep telling Claude the same thing, Munin notices and promotes it to a rule you can read.

The honest framing: claude-mem and mem0 give the model more of your past. Munin gives you a structured read on what your past sessions have been teaching Claude. Different jobs.

A workflow you can set up in 10 minutes

If you just want to stop losing yesterday's context, install claude-mem first. It's the lowest-friction option and it solves the most common flavour of this problem.

1. Clone github.com/thedotmack/claude-mem and follow the README to start the daemon on 37777.
2. Point Claude Code's hooks at it so session starts pull compressed history back in.
3. Run a normal session. Close it. Open a new one the next day and watch it reference things from yesterday without you pasting anything.

That's the floor. It stops the bleeding.

If you find yourself correcting Claude on the same thing twice in a week (your NZ English preference, your "no git add -A" rule, your specific build command), that's a different problem. Retrieval-style memory won't fix it, because the correction keeps arriving as a turn in the transcript rather than a rule the model treats as standing. That's the gap Munin is built for. Run munin friction to see which corrections keep repeating, then munin promote to push them into a rule Claude loads at session start.

Pick one. Install it today. The longer you wait, the more of yesterday's reasoning you lose.