Give Claude Code memory of your past sessions

The morning problem

Ask Claude Code “how did we fix the CORS thing last month?” and it guesses — sometimes well, sometimes expensively. Yet the actual fix, with the exact diff and your reasoning at the time, sits in ~/.claude/projects/. The agent has semantic memory about your project (that’s what CLAUDE.md is for) but no episodic memory — no access to what happened in past sessions. Those are different things: one stores rules, the other stores events, and “how did we solve this before” is an events question.

The manual workarounds

• claude --resume reopens an old conversation — the whole thing, current-project only, and you have to know which one. Good for continuing; useless for recall across history.
• Pasting old transcripts into the prompt works but burns context on mostly-irrelevant content, and first you have to find the right session (its own problem).
• Writing outcomes into CLAUDE.md is the right move for durable rules — but it only remembers what you remembered to write down, at the level of detail you wrote it.

What’s missing is the agent being able to query the history itself, mid-task, taking only what it needs.

MCP in one paragraph

The Model Context Protocol is how Claude Code talks to external tools: a server exposes a few named tools, the agent calls them when it decides they’re useful, and stdio-based servers run as a local subprocess with no network involved. Which means session history can be served to the agent the same way anything else is — as tools.

Serving your history back: turnlog mcp

Register once:

claude mcp add turnlog -- npx turnlog mcp

That starts a read-only MCP server over a local index of your sessions (built by Turnlog, free and MIT). Six tools: search — the full query language, tool:/is:error/agent: included — list_sessions, get_session, get_messages, get_context, and file_history. From then on, recall is something the agent does on its own. A real exchange, verbatim over stdio against the bundled sample sessions:

you › how did we fix the websocket reconnect?

⚙ turnlog · search { query: "reconnect" }
  13 hits · webapp — Jul 01 · $0.04
  title    WebSocket «reconnect» fix
  prompt   …Fix the «reconnect» logic in src/hooks/useWebSocket.ts
  tool_use Edit · "// «reconnect» logic missing…"

claude › Found it — "Reconnect surgery", Jul 1. You replaced the missing
reconnect with scheduleReconnect(session_id) in useWebSocket.ts; the
notes say back off exponentially.

The useful pattern isn’t the one-off question — it’s that “check how we did this before” becomes a step the agent can take inside any task: before re-deriving a migration strategy, before re-fighting a flaky test, before touching a file it has touched in five previous sessions (file_history exists precisely for that last one).

The trust properties

A tool that hands an agent your entire history should be inspectable. This one is: read-only (six query tools, no writes), stdio-only (no port, no network — it cannot phone home), and local (the index lives in your user directory; nothing is uploaded anywhere, ever — that’s structural, not aspirational). Since sessions can contain secrets, the same caution applies as to the files themselves: it serves your own machine’s history to your own machine’s agent, and nothing else.

Related: searching your history yourself · every change to one file · what’s in the files