How MCP Persistent Memory Works for Claude (Setup Guide)

Claude gets persistent memory through MCP (Model Context Protocol) by connecting to a small local server that exposes save, recall, and search tools backed by a plain file on your machine. Once an MCP memory server is configured, Claude can save a note mid-conversation and pull it back up in any future session — no re-explaining context, no cloud storage, and no vendor lock-in.

What "persistent memory" actually means for Claude

By default, every new Claude Code or Claude Desktop session starts with no knowledge of your past sessions. If you told Claude last week that your team uses a monorepo with a specific deploy process, that context is gone the next time you open a new conversation — unless you re-type it, or Claude has some way to store and retrieve it on its own.

MCP closes that gap by giving Claude tools it can call directly, the same way it calls a file-read or a shell command. Instead of you copying context back in every time, Claude decides in the moment when something is worth saving and when it needs to look something up.

How MCP gives Claude a memory, without changing Claude itself

The Model Context Protocol is an open standard for connecting AI applications to external systems — data sources, tools, and workflows — through one consistent interface instead of a custom integration per tool. An MCP server is a small local process that advertises a list of typed tools; an MCP client (Claude Code, Claude Desktop) launches that process, reads the tool list, and lets the model call those tools mid-conversation. Memory isn't a Claude feature in this model — it's whatever the MCP server on the other end decides to implement.

open-context ships exactly this kind of server, purpose-built for memory rather than a specific API integration.

The six memory tools open-context exposes

• save_context — saves a note, with optional tags and a source label, when you say things like "remember this."
• recall_context — full-text search across saved notes and tags, for "what did I say about…" questions.
• list_contexts — lists everything saved, optionally filtered by tag.
• search_contexts — multi-keyword AND search across all saved notes.
• update_context — edits an existing note's content or tags by ID.
• delete_context — removes a note by ID.

A parallel set of tools (create_bubble, list_bubbles, get_bubble) lets Claude group related notes into "bubbles" — lightweight project workspaces — so memory for one codebase doesn't bleed into memory for another.

Setting up the open-context MCP server

The server runs as a local stdio process, so setup means adding one block to your MCP client's config file.

Option A: Docker (no local build required)

Add this to ~/.claude/settings.json for Claude Code, or the equivalent Claude Desktop config:

{
  "mcpServers": {
    "open-context": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "opencontext-data:/root/.opencontext",
               "adityakarnam/open-context:latest", "node", "dist/mcp/index.js"]
    }
  }
}

The named volume keeps contexts.json outside the container, so it survives restarts and image updates.

Option B: local Node.js build

git clone https://github.com/adityak74/opencontext.git
cd opencontext
npm install
npm run build

Then point your MCP client at the built entry file:

{
  "mcpServers": {
    "open-context": {
      "command": "node",
      "args": ["/path/to/opencontext/dist/mcp/index.js"]
    }
  }
}

Restart Claude Code or Claude Desktop after editing the config — MCP servers are read once at startup, so a running session won't pick up a new one until it reloads.

What this looks like in practice

Mid-conversation, you might say "remember that this repo deploys via GitHub Actions on merge to main." Claude calls save_context with that content and a tag like deploy. Weeks later, in a completely new session, you ask "how does this repo deploy?" — Claude calls recall_context or search_contexts, finds the saved note, and answers without you repeating yourself.

This is a different workflow from the one-time preferences.md / memory.md paste described in our ChatGPT migration guide — that approach seeds Claude's native settings once from an old chat export; MCP memory keeps updating on its own, going forward, through every future session.

Privacy: where the memory actually lives

Every entry save_context writes lands in one JSON file — ~/.opencontext/contexts.json by default, or a path you set with the OPENCONTEXT_STORE_PATH environment variable. The MCP server makes no outbound network calls; it only reads and writes that local file. If you run it in Docker, mounting a named volume keeps the store outside the container entirely, so you can inspect, back up, or wipe it with ordinary file tools at any time.

FAQ

What's the difference between MCP persistent memory and Claude's built-in Manage Memory?

Claude's Manage Memory field is populated manually — you paste text in, and it stays fixed until you edit it again. An MCP memory server lets Claude call save_context, recall_context, and related tools mid-conversation on its own, so memory updates automatically and is stored as a local file you fully control.

Do I need to restart Claude Code or Claude Desktop after adding an MCP server?

Yes. Both read their MCP server configuration once at startup, so restart the app, or reload the Claude Code session, after editing settings.json or claude_desktop_config.json.

Where is open-context's MCP memory stored, and can I move it?

By default in ~/.opencontext/contexts.json as plain JSON. Set the OPENCONTEXT_STORE_PATH environment variable to store it anywhere else, or mount a Docker volume to keep it outside the container entirely.

Does the open-context MCP server work with claude.ai in the browser?

Not directly. Local MCP servers like this one connect to clients that can launch local processes, such as Claude Code and Claude Desktop. The browser-based claude.ai app uses a separate remote-integration model that this file-based, self-hosted server doesn't target.