memory

Persistent memory for Claude Code

Claude Code ships with CLAUDE.md, auto-memory, and skills. They cover the basics. When your agent needs structured, shareable, cross-tool state, an MCP server fills the gap.

What Claude Code remembers today

CLAUDE.md loads at the start of every session. Project-level files live in your repo root (shared via git). User-level files live in ~/.claude/CLAUDE.md (private to your machine). Subdirectory files give you per-package instructions inside a monorepo.

Auto-memory (MEMORY.md) lets the agent write observations between sessions. It captures your preferred test runner, naming corrections, deploy steps. It is incremental and low-friction. You do not edit these files by hand.

Skills are packaged instruction sets that load on demand. They tell the agent how to do something. The agent follows them but does not write back to them. Session resume reloads the prior conversation, but only within one session ID.

Where each one breaks

CLAUDE.md

Every line loads into every prompt, regardless of the task. A 200-line file adds 200 lines of context to a question about a typo. As teams add rules, the file grows, and prompt cost grows with it. There is no way to load only the relevant section.

Auto-memory

Auto-memory is per-machine and per-project. Start a session on your laptop and move to a remote VM: those memories do not follow. Knowledge from one repository does not carry to another, even if both projects share the same team conventions.

Skills

Skills are instructions, not accumulated knowledge. The agent cannot update them with what it learned. They do not compose into a knowledge base. Each one is a standalone document with no shared state.

Cross-tool

None of these mechanisms work outside Claude Code. Cursor does not read CLAUDE.md. Codex does not read MEMORY.md. If you use more than one coding tool, the memory is siloed in whichever tool wrote it.

The pattern: state behind an MCP server

MCP (Model Context Protocol) lets an AI tool call a server for reads, writes, and tool execution. Claude Code, Cursor, and Codex all support MCP.

Put a folder of plain text files behind an MCP server. The agent calls read_file to load what it needs and write_file to save what it learns. The folder outlives the session. Push it to git and it outlives the machine.

Because the files are plain text (markdown, YAML, JSON), you can read them, edit them, and review them in pull requests. There is no opaque database. The agent's memory is your repo.

Set it up with gcontext

gcontext is an open-source MCP server that serves a folder of plain text files as persistent state. Install it, create an instance, and start the server.

Connect Claude Code to the running server. The agent now has read_file, write_file, list_dir, and grep. Write a first piece of state to verify the connection works.

install and connect
$ uv tool install gcontext-ai
$ gcontext init my_instance
$ gcontext up my_instance
$ claude mcp add --transport http my_instance http://127.0.0.1:4242/mcp

Structure beats one big file

A gcontext instance organizes state into modules, each with an index.md entry point. When the agent works on a deploy task, it reads modules/deploy/index.md. It does not load the API docs or the style guide. The agent pulls only what the task needs.

Compare this to a 500-line CLAUDE.md that covers every topic. Every prompt pays for every line, whether or not the current task needs it. Structure lets you scale context without scaling cost.

What this does not solve

An MCP state folder is not a vector database. It does not do semantic search over millions of documents. If you need to query a large corpus by meaning, you need a RAG pipeline.

The agent must be told to write. There is no automatic capture of every conversation turn. If the agent does not call write_file, nothing is saved. A line in CLAUDE.md like "after completing a task, write a summary to modules/log.md" is enough to build the habit.

Questions

Does Claude Code have built-in persistent memory?

Yes. CLAUDE.md files load every session and auto-memory (MEMORY.md) lets Claude write notes it reads later. Both persist on disk. The limits are structure and scope: CLAUDE.md is a flat file that grows without bounds, and auto-memory is locked to one machine and one project.

Can I share memory between Claude Code and Cursor?

Not with the built-in features. CLAUDE.md is specific to Claude Code and Cursor does not read it. An MCP server solves this because both tools speak the MCP protocol. Point them at the same server and they share the same state folder.

Is CLAUDE.md enough for agent memory?

For small projects with short instructions, yes. Once your context grows past a few hundred lines, every token in CLAUDE.md loads into every prompt regardless of the task. A structured state folder lets the agent load only the files it needs, which saves context and keeps responses focused.

Related

CLAUDE.md limits
Why agent memory should not live in one markdown file
Claude Skills and MCP state
Instructions vs accumulated knowledge
Share context across tools
One state folder for Claude Code, Cursor, and Codex
What is agent state?
Definition and management patterns
Give your agent a memory that lasts

Install gcontext and connect Claude Code in two minutes.

View on GitHubBrowse agents