Claude Memory Across Sessions: What Carries Over

John Rood··5 min read

Every Claude session ends. The work does not. The question is what the next session gets to keep.

Today, Claude's own layers cover some of it: the open conversation's context window, project instructions and project knowledge, plus the memory Claude chooses to save. In Claude Code, there is CLAUDE.md and the notes the tool keeps on the machine.

The gap is consistent, and it is not about facts. It is the decision trail: what you settled, why, what you rejected, and where the task stands. Open a fresh conversation and ask what you decided about the queue design yesterday. It can answer only if something durable captured that decision. Usually, nothing did.

MemoryRouter closes that gap with a vault outside every client and a connection per surface. Here is how each Claude surface behaves, and what to add where.

What persists in Claude today

The context window. Inside a session, everything is available, up to the window limit. This is the layer people mistake for memory.

Project instructions and knowledge. Static. You write it down, and every chat in the project pays the token cost of reading it. Excellent for standing rules. It cannot hold Tuesday's decision unless you hand-edit it after the fact, which nobody does mid-task.

Claude's memory. What Claude decided to save. Useful, and it lives inside Claude. It does not travel to Cursor or Codex.

Claude Code specifics. CLAUDE.md plus local state maintained by the tool. The conversation is not part of that stack, and compaction trims the conversation to a summary mid-session.

So the durable stack is real but thin, and all of it lives inside Anthropic's surfaces. The moment your work spans tools, you need a layer that belongs to none of them.

Three places continuity breaks

  • You fix a subtle bug and the fix depends on an environment quirk. New session, same bug, because the quirk lived in the chat.
  • You draft a plan with Claude and never move it to a document. The session ends mid-plan, and tomorrow's session has a fresh opinion, which is worse than no plan.
  • You correct something ("this repo uses named exports everywhere"). The correction holds for the rest of that chat and evaporates at the boundary.

None of these are factual memory failures. They are failures of the trail the work leaves behind, and the trail is exactly what a context window deletes.

The connector path: claude.ai chat and Cowork

Claude supports custom connectors, which is the official way to attach an MCP server. The setup:

  1. Open Customize, then Connectors. On an individual plan, choose Add custom connector. On Team and Enterprise, an owner adds it under Organization settings first, then members connect.
  2. Paste the server URL: https://mcp.memoryrouter.ai/mcp
  3. Sign in through OAuth and choose the vault this connection uses.

Leave the advanced OAuth client ID and secret fields empty; discovery and dynamic registration handle it. The full click path, plan differences, and admin notes are in the connector documentation.

Once connected, Claude gets memory tools: search for semantic recall, date search for time-window questions ("what did we settle last month"), store for explicitly approved saves, and status to check the binding. Claude decides when to call them, so be direct. "Search MemoryRouter for how we handle retries" is a normal instruction, not a workaround.

Prove it in one pass. In a connected conversation, ask Claude to store a synthetic fact. Confirm the tool call succeeded by looking at the actual result, not at a confident reply. Then open a fresh conversation with the connector enabled and ask Claude to search for that fact without repeating it. A real answer with a tool result proves cross-session recall. A plausible sentence without a tool call proves nothing.

The hooks path: Claude Code

Claude Code does not need to decide anything. npx -y memoryrouter-claude init installs lifecycle hooks: recall before each prompt, capture after each completed turn (one user prompt and one final assistant response, with tool payloads excluded), and re-injection after compaction, resume, and fork. The Claude Code page walks through the install, and the documentation covers scope choices, verification, and removal.

The practical effect on sessions: closing the terminal no longer resets the project. Neither does compaction, which is the more annoying one, because it happens mid-task and silently.

One vault, every Claude surface

This is the cross-AI memory pattern at work. Point the connector and the hooks at the same vault and the surfaces stop being separate silos. A decision recorded in Claude Code is available in a browser conversation, and the reverse. Cowork, chat, and the CLI become views onto the same project history instead of three disconnected assistants.

Keep two boundaries in mind. Claude's native memory and MemoryRouter are separate systems, which is why the test above checks the tool result. And one connection binds to one vault, so strict separation between work and personal context means two vaults and two connections.

The two-session checklist

  1. Connect one Claude surface.
  2. Store a decision you actually care about, and check the tool result.
  3. Start a fresh session and ask for it without providing context.
  4. Repeat with a second surface on the same vault.

Four steps, ten minutes. After that, "new session" stops meaning "start over."

If you only use Claude through the browser, the connector alone gets you most of the way. The hooks matter most for long coding sessions, where compaction and session boundaries are routine rather than occasional. Connecting more than one surface to the same vault is normal, and the memories do not conflict: each conversation retrieves what is relevant to it.

Create your MemoryRouter account and connect the Claude surfaces you use.