DEV Community

decker
decker

Posted on • Edited on

I tried 3 different ways to fix Claude Code's memory problem — here's what actually worked

I lost a full afternoon's work last week.

Four hours of debugging a gnarly database migration, maybe 30 back-and-forth messages with Claude Code about the exact schema evolution. Then I closed the terminal, came back after dinner, started a new session — and Claude had no idea what we'd figured out. The CLAUDE.md I'd written was vague. The git commits were there but the why was gone.

This is the Claude Code memory problem, and if you code with AI tools regularly, you've hit it. Each session is a blank slate. The context you built up — the decisions, the dead ends, the "wait, we tried that and it failed because..." — evaporates.

I spent the last couple weeks trying three different approaches. Here's what happened.


The problem in concrete terms

Before I get into solutions, let me be specific about what I was trying to solve. There are actually two distinct problems people conflate:

Problem A — Intra-session compaction: Claude Code compacts conversation history during a long session to stay within context limits. You lose early conversation detail while still coding. Annoying but manageable.

Problem B — Cross-session continuity: You close the terminal. New session tomorrow. Claude knows nothing of yesterday's decisions. This is the one that kills me.

I was mostly solving Problem B. Keep that in mind as you evaluate these approaches.


Approach 1: The CLAUDE.md + structured notes system

What it is: You maintain a CLAUDE.md at the project root, and you religiously update a notes/ folder with session summaries after each coding session.

How I set it up: I created notes/YYYY-MM-DD.md files after each session, writing 5-10 bullet points of "what we decided and why." The CLAUDE.md pointed Claude to read these files at the start.

What worked: Claude actually got surprisingly good at picking up context from well-written notes. If I took 3 minutes at session end to write "decided to use optimistic locking instead of row-level because of X", the next session started with that knowledge intact.

What didn't: The discipline. I skipped writing notes maybe 40% of the time — usually when I was tired, or when the session ended in frustration. Those were exactly the sessions where the context mattered most. Also, notes are lossy. They capture what I thought was important, not what Claude actually found important during the conversation.

Verdict: Works if you're disciplined. I'm not always disciplined.


Approach 2: SQLite memory layer via MCP

A few people in r/ClaudeAI have been building local SQLite-backed memory servers that expose themselves as MCP tools. The idea: Claude writes key facts to a database during the session, reads them back at the start of the next one.

What I tried: I found a few open-source implementations, set one up. The MCP server runs locally, Claude Code connects to it and has access to remember() and recall() type tools.

What worked: When Claude remembered to use it, it was actually pretty good. I'd ask it to remember a decision, and it would. The memory persisted across sessions because SQLite is durable.

What didn't: Two issues. First, Claude doesn't always reach for the memory tool when you'd want it to. You have to prompt it or add instructions to CLAUDE.md to remind it to save decisions. It's not autonomous. Second — and this one surprised me — it saves semantic knowledge but not state. It can remember "we decided on optimistic locking" but it can't tell me "at the point where we made this decision, the schema looked like this." There's no connection to what the code actually was at that moment.

Verdict: Good for explicit knowledge. Weak on tying memory to code state.


Approach 3: Session replay tied to git state

This is what I ended up landing on. The tool is Mantra — it records your AI coding sessions and links each message to the corresponding git state. So you can actually scrub back through a past session and see what the code looked like at the moment a decision was made.

What worked: The time travel part is genuinely useful. I was debugging something last week, hit a wall, and scrubbed back through a session from 3 days ago to find the exact moment we refactored a function that I suspected was the cause. Took maybe 2 minutes. Without this I'd have been reading git history trying to reconstruct the narrative.

The replay also captures context I wouldn't have thought to write down in notes — the questions I asked, the paths Claude suggested and I rejected, the chain of reasoning. That stuff is often more useful than the final decision.

What didn't: The tool is local-first and currently pretty minimal. It doesn't write memory back to Claude — it's a read/review tool, not an automatic context injection system. You have to actually look at it. For cross-session continuity, I still start sessions by briefly reviewing relevant past sessions, then writing a tighter prompt with what I found. It's manual but at least the information is there.

Verdict: The best solution for recovering context after the fact. Doesn't solve the "Claude starts fresh" problem automatically, but makes the manual recovery process much faster.


What I actually do now

Combination approach. The SQLite MCP handles explicit "remember this" moments. Mantra captures the full session history so I can review it later. And I write CLAUDE.md notes, but shorter and more ruthlessly selective — only the non-obvious stuff.

For most projects, this gets me maybe 80% of the continuity I want. The remaining 20% is the stuff I genuinely can't reconstruct: the nuanced direction we were heading, the three alternatives Claude laid out in detail that I said "let me think about that."

That part I've made peace with losing. You can't have perfect memory in a tool that was designed session-by-session. What you can do is recover faster when you need to.


The uncomfortable truth

None of these solutions are great. They're workarounds for a tool design limitation.

The real fix would be native session persistence — where Claude Code can optionally pull in relevant history from past sessions automatically, without you having to manually manage CLAUDE.md files or MCP memory servers. Some people are building toward this. A few GitHub issues on the Claude Code repo have been open for a while requesting exactly this feature.

Until then, the combination above is the best I've found. If you have a different setup that works better, I genuinely want to hear it in the comments.


If you want to try the session replay approach: Mantra is free, no account required, works with Claude Code, Cursor, and Gemini CLI.


FAQ

Does Mantra work with Cursor?
Yes — Cursor v0.40.0+ is fully supported. Gemini CLI and Codex as well.

Does the SQLite MCP approach work with other AI coding tools?
If the tool supports MCP, yes. Claude Code has solid MCP support. Cursor's is improving.

Won't all this overhead slow down my actual coding?
The session-end note-writing takes 3-5 minutes. The replay tool is passive — it records automatically. The MCP memory only costs time when you explicitly ask it to remember something. In practice the overhead is small compared to the time I used to spend reconstructing lost context.

Top comments (0)