Every coding assistant — Claude Code, Cursor, Windsurf, Copilot — starts each session with a blank context window. The tools for giving them persistent memory fall into three layers: built-in file-based memory (CLAUDE.md, .cursorrules, instructions files), tool-specific auto-memory (Claude Code’s auto memory, Cursor’s memory), and external memory layers connected via the Model Context Protocol (MCP) that work across all tools. The right layer depends on whether you need memory within one tool, across tools, or across tools and models.
You correct your coding assistant’s approach to error handling on Monday. On Tuesday, it makes the same mistake. You explain your testing framework in Cursor; that night, in Claude Code, you start from zero. You switch from Windsurf to the terminal for a quick fix — and none of the context carries over.
This is the fundamental constraint of LLM-based coding tools: the model has no persistent state between sessions. The context window resets, and everything you taught it is gone. Zhang et al. (arXiv:2404.13501) identify memory as “the key component” enabling agent self-evolution — the ability to improve through experience rather than re-explanation. Without memory, every session is ground zero.
The fix is to externalize memory — store what the agent learned so it survives the session boundary. Three layers of tools do this, each solving a different scope of the problem.
Most coding assistants support a project-level instructions file that is loaded into context at the start of every session. This is the simplest form of persistent memory: you write down what the agent should know.
| Tool | File | What it does |
|---|---|---|
| Claude Code | CLAUDE.md | Instructions loaded every session; supports project, user, and org scopes. Also reads .claude/rules/*.md with path-scoped frontmatter. (code.claude.com/docs/en/memory) |
| Cursor | .cursorrules / Rules | Project instructions loaded into context. Cursor’s Customize system supports rules, skills, plugins, and MCP from one place. |
| Windsurf | .windsurfrules | Project instructions for the Windsurf coding agent. |
| GitHub Copilot | .github/copilot-instructions.md | Custom instructions loaded into Copilot’s context. |
| AGENTS.md | AGENTS.md | Cross-tool convention — some agents read AGENTS.md; Claude Code can import it via @AGENTS.md in CLAUDE.md. |
How it works: You write a markdown file with build commands, coding standards, architectural decisions, and “always do X” rules. The assistant reads it at session start. Run /init (Claude Code) or equivalent to auto-generate a starting file from your codebase.
Limitations: File-based memory is tool-specific (CLAUDE.md is not read by Cursor), has no semantic search (the full file loads every session), and has no feedback or decay mechanism. It is instructions, not learned knowledge.
Some coding assistants now write their own memory files automatically, based on your corrections and preferences.
Claude Code auto memory (v2.1.59+) lets Claude accumulate knowledge across sessions without you writing anything. Claude saves notes for itself — build commands, debugging insights, architecture notes, code style preferences — in ~/.claude/projects/<project>/memory/. The first 200 lines of MEMORY.md are loaded into every session. Claude reads and writes memory files during the session, keeping MEMORY.md as an index and moving details into topic files. It is on by default, machine-local, and per-repository (code.claude.com/docs/en/memory).
Cursor supports a memory system through its Customize framework (rules, skills, plugins, MCP). Cursor’s agent can maintain context within a project and across sessions within the same workspace.
Limitations of tool-specific auto-memory: Locked to one tool (Claude Code’s auto memory is not read by Cursor, and vice versa). No cross-project knowledge transfer. No semantic recall — memory is loaded by file, not by relevance. No feedback loop to rate memory quality. No provable erasure of individual memories.
The Model Context Protocol (MCP) is an open protocol — JSON-RPC 2.0 based, inspired by the Language Server Protocol — that standardizes how LLM applications connect to external data sources and tools (modelcontextprotocol.io/specification/2025-11-25). It is transport-level: it defines how an agent talks to a memory server, not what format the memories are in.
MCP is the bridge that lets a single memory layer serve Claude Code, Cursor, Windsurf, and other MCP-compatible tools. Instead of each tool having its own isolated memory, one external memory server is connected to all of them.
Packer et al. (arXiv:2310.08560) demonstrated the core insight with MemGPT: agents need managed memory, not more parameters. By managing memory externally in tiers — core memory in the context window, archival memory retrieved on demand — agents dramatically outperform models that try to hold everything in the context window. MCP makes this architecture practical: the memory server is the archival tier, and MCP is the retrieval protocol.
| Tool | License | Stars (Jul 2026) | Memory format | Key feature |
|---|---|---|---|---|
| PLUR | Apache-2.0 | ~217 | Human-readable YAML engrams | Local-first, open format, activation decay, feedback signals |
| Mem0 | Apache-2.0 | ~60.5K | Vector + graph store | CRUD API, entity linking, 92.5 LoCoMo score |
| Graphiti/Zep | Apache-2.0 | ~28.6K | Temporal knowledge graph | Time-aware retrieval, sub-200ms queries |
| Cognee | Apache-2.0 | ~27.4K | Knowledge graph | Ingest from any format, self-hosted |
| MCP server-memory | MIT | — | Basic knowledge graph | Official reference implementation |
PLUR (github.com/plur-ai/plur) stores memory as plain-text YAML engrams — each engram is a typed assertion (“always use blue-green deploys”, “never force-push to main”) with activation strength that decays over time (ACT-R model), feedback signals, and hierarchical scoping. Setup for Claude Code is one command (npx @plur-ai/mcp init), and it works with Cursor, Windsurf, and OpenClaw through the same MCP server. Search is fully local: BM25 + BGE embeddings + Reciprocal Rank Fusion, zero API calls. Memory is stored in ~/.plur/engrams.yaml — a file you can open, read, edit, and version-control.
The key differentiator: PLUR stores memory in a human-readable, open format. You can diff your memories in git, write tooling against the published JSON Schema, or build a different engine on the same format. Engrams include provenance (where the memory came from and when), confidence scores, and polarity (do vs. don’t rules injected separately).
Mem0 (github.com/mem0ai/mem0) is a memory layer with vector + graph storage and a CRUD API. The official OpenMemory MCP server connects it to Claude Code and other tools. Mem0’s April 2026 algorithm update reports 92.5 on LoCoMo and 94.4 on LongMemEval benchmarks (arXiv:2504.19413), with 91% lower p95 latency and 90%+ token cost savings versus full-context approaches. Memory is stored as vector embeddings with entity linking — not human-readable, but the API is straightforward and benchmarks are strong.
Graphiti (github.com/getzep/graphiti) builds real-time temporal knowledge graphs for agents. Memory is stored as graph edges with temporal validity windows — facts have a “valid from” and “valid to” timestamp, so the agent can reason about how knowledge changes over time. The Graphiti MCP server connects it to coding assistants. This is uniquely useful for codebases where facts change (API endpoints move, schemas evolve, dependencies upgrade).
Cognee (github.com/topoteretes/cognee) is an open-source AI memory platform using knowledge graphs. It ingests from any format (documents, code, conversations) and builds a self-hosted graph. Cognee works with Claude Code and OpenClaw through plugins.
@modelcontextprotocol/server-memory is the official reference implementation — a basic knowledge graph that any MCP client can read and write. Simpler than Mem0 or Graphiti, but useful for getting started with MCP-based memory and understanding the protocol.
If you work in one tool only: Start with the built-in file-based memory (CLAUDE.md, .cursorrules). It requires no setup and handles the most common need. Enable auto-memory if your tool supports it.
If you work across multiple tools (Claude Code + Cursor + terminal): You need an MCP memory server. The question is which format: vector embeddings (Mem0), temporal knowledge graphs (Graphiti), or human-readable YAML engrams (PLUR).
If you need to inspect, edit, or prove erasure of memories: Choose a tool with an open, human-readable format. PLUR stores engrams as YAML files you can open in any editor and delete with proof. Vector-based systems (Mem0) are inspectable via API but not human-readable. Knowledge graphs (Graphiti, Cognee) are queryable but not designed for line-by-line editing.
If you need memory to improve over time: Look for feedback loops and activation decay. PLUR supports both — positive/negative ratings train injection quality, and unused memories fade via ACT-R decay. Mem0’s April 2026 update added temporal reasoning but not feedback-driven decay.
If you need provable GDPR erasure: External memory is fundamentally better than model-native memory. GDPR Article 17 gives individuals the right to erasure “without undue delay” (gdpr-info.eu/art-17-gdpr). With an external memory layer, deletion is one operation: remove the memory item. With fine-tuned model weights, erasure requires “machine unlearning” — a notoriously difficult problem (Bourtoule et al., arXiv:1912.03817). See Editable and Auditable Agent Memory for details.
| Built-in files | Tool-specific auto-memory | MCP memory server | |
|---|---|---|---|
| Setup effort | None (write a file) | None (enabled by default) | One command to install |
| Cross-tool | No (tool-specific format) | No (locked to one tool) | Yes (any MCP client) |
| Semantic recall | No (full file load) | No (file-based, first N lines) | Yes (BM25 + embeddings) |
| Feedback loop | No | No | Varies (PLUR: yes) |
| Decay | No | No | Varies (PLUR: ACT-R) |
| Inspectable | Yes (markdown files) | Yes (markdown files) | Varies (PLUR: YAML; Mem0: API; Graphiti: graph query) |
| Provable erasure | Yes (delete file) | Yes (delete file) | Yes (delete memory item) |
| Cross-project | No (per-repository) | No (per-repository) | Yes (global or scoped) |
What tools let me give a coding assistant persistent memory? Three layers: built-in file-based memory (CLAUDE.md for Claude Code, .cursorrules for Cursor), tool-specific auto-memory (Claude Code auto memory v2.1.59+), and external memory layers connected via MCP (PLUR, Mem0, Graphiti, Cognee). Built-in memory is simplest but locked to one tool. MCP memory servers work across all MCP-compatible coding assistants.
Can I share memory between Claude Code and Cursor? Built-in memory cannot transfer — CLAUDE.md is not read by Cursor, and .cursorrules is not read by Claude Code. To share memory across tools, use an MCP memory server. Any MCP-compatible agent can connect to the same server, so memory written from Claude Code is immediately visible in Cursor, Windsurf, and other tools.
What is the best memory tool for a coding assistant? It depends on your needs. For single-tool use, the built-in CLAUDE.md or .cursorrules is sufficient. For cross-tool memory, choose an MCP server: PLUR for human-readable, local-first engrams with feedback and decay; Mem0 for high-benchmark vector + graph memory with a CRUD API; Graphiti for temporal knowledge graphs that track how facts change over time.
How does MCP memory work with coding assistants? MCP (specification 2025-11-25, modelcontextprotocol.io) is an open protocol that standardizes how LLM applications connect to external tools. A coding assistant (Claude Code, Cursor) acts as an MCP client and connects to a memory server. The server exposes tools like “store this memory” and “search for relevant memories” that the assistant can call during a session. Memory persists on the server, so it survives across sessions and is available to any MCP-compatible tool.
Is CLAUDE.md the same as agent memory? CLAUDE.md is a form of persistent memory — instructions you write that are loaded every session. But it is static (you write it manually), not semantic (the full file loads, not just relevant parts), and tool-specific (Claude Code only). A full agent memory layer adds semantic recall, feedback, decay, and cross-tool portability. See What Is Agent Memory? for the full concept.
How do I add memory specifically to Claude Code? Claude Code has two built-in mechanisms — CLAUDE.md files and auto memory (v2.1.59+) — plus MCP memory servers for cross-tool memory. See How to Add Persistent Memory to Claude Code for a detailed walkthrough of each approach.