Why Claude Forgets Everything Between Conversations — and How to Work With It

Published June 2026 · 6 min read

If you've used Claude for more than a week, you've hit this. You had a great session. You explained your project, your constraints, the context behind the work. Claude was helpful. You got something done.

Next day, you open a new conversation: Claude has no idea who you are or what you were working on.

This is frustrating, but it's not a bug. Understanding why it works this way makes it easier to work around.

Why Claude forgets — the actual reason

Claude doesn't maintain a persistent memory of your conversations for two reasons that, once you understand them, make sense:

Privacy. If Claude remembered everything across sessions by default, every conversation you had would be stored indefinitely and potentially used to influence future conversations. Some users would find this useful. Many would find it concerning. The default of not persisting anything is the conservative, privacy-respecting choice.

Cost. Every token in Claude's context window costs compute. If Claude loaded six months of your conversation history at the start of every session, that would be expensive to run and slow to process. Blank-slate sessions are fast and cheap.

These are deliberate design decisions, not oversights. They won't change, and there's a reasonable argument they shouldn't.

The wrong ways to work around it

Most people try one of two approaches, and both have problems:

Custom instructions — You can put stable facts about yourself in Claude's system prompt (Settings → Custom instructions). Claude loads these in every conversation. This works for preferences and background, but it's global and static. You can't use it to tell Claude what you're working on this week. You'd be editing Settings every time the project changed.

Copy-paste — Starting each session by pasting the relevant parts of previous conversations. This works but it's slow, the pasted text is noisy, and you have to decide what's relevant every time. If you're doing this for more than one or two sessions, you're spending real time on re-briefing.

Neither approach scales past a single simple project. Neither lets Claude actively retrieve what's relevant — you have to push the context in manually.

The right model: a store Claude queries on demand

The better pattern is a persistent store that Claude can read in any session. You curate what goes in it; Claude queries it when you need context. The session starts without loading everything — Claude fetches what's relevant, when it's relevant.

This is what MCP connectors make possible. Stash is a hosted MCP store: you connect it to Claude in Settings, write records to it during sessions, and query it in future sessions with a single call.

Here's what a re-briefing looks like with this pattern in place:

User: context("freelance-clients")

Claude: Found 3 records in freelance-clients:

  Marsh & Co: Branding project. Currently mid-deliverable on the brand
  guidelines document. Main contact is Sarah (sarah@marshandco.com).
  Prefers Slack over email. Budget approved to £4,200; spent ~£2,800.
  Next milestone: logo variants by 15 June.

  TechStart: Website copy. On hold — waiting for them to confirm the
  new product positioning. Follow up next Monday.

  Oaken Legal: Ongoing retainer. Monthly meeting last held 2 June.
  Action items from that meeting: update the services page, draft Q3
  newsletter. No deadline pressure, just keep moving.

Three seconds. Claude is briefed on three active client relationships without the user explaining anything. The session can start immediately.

Later in the session, the user updates a record:

User: TechStart confirmed the positioning. They're going with "AI-first
for regulated industries". Update their record in freelance-clients.

Claude: Updated TechStart in freelance-clients — positioning confirmed as
"AI-first for regulated industries", status back to active.

The next session, that update is there. The memory compounds over time.

What to store — and what not to

The most common mistake is trying to store too much. Stash works best as a curated interpretive layer, not an archive of everything. What to store:

• Active project or client status — current state, open decisions, next steps
• Context that would take minutes to re-explain — backstory, constraints, rationale
• Things Claude explicitly helped you work through — decisions, recommendations, conclusions worth keeping
• Reference information you query occasionally — recurring checklists, templates, personal glossaries

What not to store:

• Conversation transcripts. Too long, too noisy. Summarise instead.
• Information that changes daily. Not worth the maintenance overhead.
• Secrets or credentials. Never. Not API keys, passwords, or personal identifying information beyond what you're comfortable with.
• Things already well-documented elsewhere. If it's in your project README, don't duplicate it — just reference it.

Being honest about the tradeoff

Stash doesn't make Claude automatically remember things. You still have to decide what's worth storing. You still have to call context() at the start of a session when you want Claude briefed. This is more deliberate than some users want.

But deliberate is actually an advantage here. You're in control of what context Claude has. You can keep sensitive things out. You can update records when they change. You can have separate collections for separate projects. And because you've curated what's there, what Claude retrieves is signal, not noise.

The alternative — automatic memory of everything — trades that control for convenience. Whether that's the right tradeoff is a personal choice. For users who want to work with Claude on multiple projects, or who handle client information, or who want to be careful about what an AI system holds about them, the explicit model is the better one.

Getting started in five minutes

1. Add the Stash connector (URL below) in Claude's settings (Settings → Connectors → Add custom MCP).
2. In any Claude session: "Create a collection called [your project name] and save [the most important context you'd otherwise have to re-explain]."
3. Next session: "context([your project name])" — Claude will retrieve it.

Start with one collection and one project. Build from there as it proves useful.

Pricing

Free tier covers individual users getting started. Pro (£8/month) removes limits for heavier use across multiple projects or clients. Pricing may change; cancel anytime.