Persistent Memory for Claude Desktop with MCP (Now That Claude Has Its Own)

Originally published on contextforge.dev.

When I wrote the setup guide for giving Claude persistent memory over MCP in March, Claude Desktop had no memory of its own. You closed the window and that was it. That is no longer true. Claude now saves memories on its own, lets you read and edit them in Settings, and keeps a separate memory per project. So if you're searching for persistent memory for Claude Desktop with MCP today, the honest question isn't how anymore. It's whether, and for what.

I build a memory server, so you'd expect me to say yes. The real answer is: it depends on what you need remembered. Here is what the built-in memory keeps, where it stops, and the two situations where memory over MCP earns its place next to it.

TL;DR: Claude Desktop's own memory is about you: topics, preferences, ongoing threads, saved as you chat and editable in Settings. It stays inside your Claude account. It does not reach Claude Code, Cursor, a teammate, or a repo, and it has no idea when the code it describes changed. If you only use Claude Desktop and you want it to remember you, turn it on and stop reading. If the thing you need remembered is a project (decisions, reasons, the branch you were on) that other tools or people also touch, that's the job of a memory server over MCP, and you can run both.

What Claude Desktop remembers on its own

The current memory feature, per Anthropic's help center, works like this:

• Claude saves memory as individual topics while you chat, rather than summarizing afterwards. You can also say "remember this."
• Each project has its own memory. In a project chat, Claude uses that project's memory plus your account memory, never another project's.
• You can read, edit and delete every topic under Settings → Your Claude → Manage memory, or just tell Claude to change or forget something.
• Chat search (paid plans) lets Claude look up earlier conversations when you ask. It shows up as a tool call and cites the chat it found.
• Incognito chats are never saved or searched. Sensitive topics are excluded by default.
• It's on by default for Free, Pro and Max on web, Desktop and mobile, as two toggles under Settings → Memory ("Search and reference chats" and "Generate memory from chats"). On Team and Enterprise an owner has to enable it, and owners cannot read members' memories.

That is a real memory. It's better than what most people had in March, and for a lot of use it is enough. The limits only show up when you look at what it is about and where it lives.

Where it stops

	Claude Desktop built-in memory	Memory over MCP (ContextForge or similar)
What it remembers	Topics about you and your ongoing conversations	Whatever the agent saves: decisions with the reason, project facts, tasks
Where it lives	Inside your Claude account	A server any MCP client can reach
Reaches Claude Code / Cursor	No	Yes, same memory from every tool
Reaches a teammate	No (owners can't even see it)	Yes, if you share the project
Tied to a repo or branch	No	Yes, memories link to a project and the files they describe
Knows when the code changed	No	Freshness check flags memories whose files changed
How it's recalled	Claude decides what's relevant	The agent runs a search, or you ask "why did we…"
What a reset does	Deletes everything, including project memories	Export, snapshot, restore

Two rows matter more than the rest. Reach: the built-in memory stops at the edge of the Claude app. The decision you made in Claude Desktop at 3 pm does not exist for Claude Code at 5 pm, and it never will, because the two don't share a store. Unit: the built-in memory is organized around you. A memory server is organized around a project, which is where "why did we make the landing page static" needs to live if a fresh session is going to stop contradicting it.

When the built-in memory is enough

Be honest with yourself about this one, because adding a server you don't need is just another thing to maintain.

• You use Claude Desktop and nothing else. No Claude Code, no Cursor, no API.
• What you want remembered is about you: how you like answers, what you're working on this month, the names of the things in your life.
• Nobody else needs to see it.
• No code is involved, or the code never changes under the memory.

If that's you, turn memory on, open Settings once to see what it saved, and you're done. I mean it.

When you need memory over MCP

• You use more than one tool on the same project. This is the big one. Claude Desktop for thinking, Claude Code for building, maybe Cursor for the UI. The built-in memory lives in the first one only. Sharing context between Claude Code and Cursor is the same problem with different names.
• The memory is about decisions, not preferences. "We chose soft deletes because the audit log needs the rows" has to be findable from any session, with the reason attached, or it gets re-decided.
• Someone else works on it. A teammate's Claude has never heard of your Claude's memory.
• The thing it describes changes. A memory that says "we're on Prisma" is actively harmful two weeks after you moved off it. Claude's built-in topics don't know your code moved. A memory server that links memories to files can flag them when those files change, which is the whole point of not letting your context go stale.

Setting it up in Claude Desktop

This part is short because the March guide has the long version. Claude Desktop reads MCP servers from one JSON file:

# macOS
~/Library/Application Support/Claude/claude_desktop_config.json
# Windows
%APPDATA%\Claude\claude_desktop_config.json

Add the server and your API key, then quit Claude Desktop completely (Cmd + Q on macOS) and reopen it:

{
  "mcpServers": {
    "contextforge": {
      "command": "npx",
      "args": ["-y", "contextforge-mcp"],
      "env": {
        "CONTEXTFORGE_API_KEY": "your-api-key-here"
      }
    }
  }
}

One thing that changed since March: Claude Desktop honors the instructions an MCP server declares about itself. Since contextforge-mcp 0.5.1 those instructions tell Claude to query memory before answering about a project and to save decisions as they happen, so on Desktop it gets used without you writing a system prompt for it. The init command and the post-compaction hook from the Claude Code guides don't apply here; Desktop has no compaction event to hook.

Running both, or just one

Full disclosure: on my own Claude Desktop both memory toggles are off. Not because the feature is bad, but because everything I'd want remembered is about a project, and I'd rather have one place to check than two. That's a preference, not a rule.

If you keep Claude's memory on, the two don't fight. Leave the built-in one for you. Point the project at the memory server. The one habit that makes it work is saying, once per project, something like: decisions and project facts go to ContextForge; use chat memory for me. After that the division holds on its own, because the server's instructions already push project decisions its way.

The honest caveat: you will occasionally get the same fact in both places. That's harmless. The harmful case is the opposite one, a decision that lives only in Desktop's memory and is invisible to the session that needed it.

What this doesn't fix

• Memory over MCP is only as good as what got saved. If the agent never recorded that the migration uses soft deletes, no search will invent it.
• It doesn't make Claude's built-in memory reach other tools. Nothing does; it's inside the account by design.
• It's a small team's product. Setup is one JSON block, but if you want the post-compaction recall that Claude Code gets, that's a Claude Code feature, not a Desktop one.
• None of this replaces reading your own code. It replaces re-explaining it.

FAQ

Does Claude Desktop's memory work in Claude Code?
No. The help center describes it for web, Desktop and mobile. Claude Code has its own mechanisms (CLAUDE.md, auto-memory, --resume) and they don't share a store with the app either.

Can I see what the MCP memory saved, the way I can in Settings?
Yes. Every memory is an item in a space in the dashboard, with the title, content and the files it references. You can edit, correct or delete it there or by asking the agent.

Do I have to turn Claude's memory off to use a memory server?
No. They coexist. Keep the built-in one for yourself and use the server for the project.

One thing to do today

Open Settings → Your Claude → Manage memory and read what Claude saved about you this month. Then ask yourself one question: is anything in there a project decision that Claude Code or a teammate would need tomorrow? If the answer is yes, that's the memory that needs to live somewhere both of them can reach.