Claude Code Memory: What Persists, Where It Lives, and How to See What Claude Has Learned

Memory is where most of the useful work with LLMs now happens. It lets your model keep track of the ideas and design decisions you care about across repositories, instead of leaving each project in its own silo.

Claude Code's own memory was built for a simpler job. It is made of files. CLAUDE.md holds the instructions you write and loads at the start of every session. Auto memory is what Claude writes for itself about your project, indexed in a MEMORY.md file in a per-project memory directory under ~/.claude/projects. Anything connected over MCP can be read on demand. All of it is flat text, and all of it lives on one machine.

That is enough to stop Claude Code from asking the same questions twice. It is not enough to tell you what it has learned, which facts it keeps rediscovering, or how to carry that knowledge to another repository, knowledge base, vault, machine or another client such as Cursor. If you work on more than one project, share a codebase with a team, or want to connect ideas that live in different places, the default setup runs out quickly.

A graph memory over the InfraNodus MCP server gives you a structure you can see and a memory that travels with you. It also shows the gaps, the places where nothing connects, so you can bridge them with new ideas and tighten your knowledge base, design briefs, or repository learnings.

Below: how Claude Code memory works by default, then the graph memory setup next to it, so you can decide which one your projects need.

How Claude Code Memory Works

Claude Code memory has two native mechanisms, both loaded at the start of every conversation: CLAUDE.md files, which you write, and auto memory, which Claude writes. CLAUDE.md lives in your project, your home directory, or a managed policy location, and holds rules. Auto memory lives in a memory directory under ~/.claude/projects/ and holds what Claude learned from your corrections. Both are context, not enforced configuration: Claude reads them and decides.

CLAUDE.md files stack. Claude Code loads the file in your working directory and every directory above it, then any .claude/rules/*.md files, then CLAUDE.local.md for private preferences you keep out of git. A @path/to/file line imports another file at launch. The project CLAUDE.md committed to git is the team's shared memory; Claude also reads an existing AGENTS.md in its place. Run /init to generate a first CLAUDE.md from the codebase, /memory to list and open every memory file, and /context to see which files loaded. Compaction is not memory: when the context window fills, Claude Code summarizes the conversation, and the summary dies with the session.

What Claude Code Auto Memory Saves, and Where

Claude Code auto memory is the notes Claude writes for itself, without being asked, when it decides something will matter in a future conversation. It records four kinds: user (your role and preferences), feedback (corrections you gave and approaches you confirmed), project (decisions it cannot derive from the code or git history), and reference (where to find things outside the repo). It skips what the codebase already says and what CLAUDE.md already covers.

The files are plain markdown in ~/.claude/projects/<project>/memory/. MEMORY.md is the index, one line per memory; each memory is its own topic file with frontmatter and a modified timestamp. The first 200 lines or 25 KB of the index load at every start. Topic files load only when Claude reads them. A correction you give becomes one line in the index and one topic file: the next session loads the line, not the reasoning behind it. When the index nears the limit, Claude Code tells Claude to merge or drop stale entries and move detail into topic files; some write-ups call this consolidation "auto dream". You can open any of these files from /memory, edit them, or delete them.

~/.claude/projects/<project>/memory/
├── MEMORY.md             # index, one line per memory
├── feedback_build.md     # "src/ edits need npm run build, then restart"
├── project_outage.md     # "server-side events dead since Jul 1"
└── reference_dashboard.md

Auto memory is on by default in local sessions. Turn it off for one project with "autoMemoryEnabled": false in that project's settings, or everywhere with CLAUDE_CODE_DISABLE_AUTO_MEMORY=1. It is machine-local: every worktree of the same repository shares one directory, and no other machine, cloud session, or client sees it.

The catch is the shape. The index is a list. Nothing in it shows which memories relate to each other, which facts Claude keeps relearning because they never made it into a line, or which parts of the project it has never formed a memory about. The only way to review what Claude Code has learned is to read the files one by one.

Which Knowledge Belongs in Which Layer

Once you can see the shape of the two native layers, the question is what to put in each. Rules go in CLAUDE.md, facts Claude discovers go in auto memory, and relations that must outlive the machine go in a graph. The official guidance for CLAUDE.md is under 200 lines per file: imperative, specific, nothing Claude can derive from the code. When a CLAUDE.md grows past a screen, move path-specific rules into .claude/rules/ and long references behind an @import. Review it when a rule stops being followed, which usually means two rules contradict each other.

Auto memory takes what you would otherwise repeat in chat: "the API tests need a local Redis", "the client prefers pnpm". It is the right place for facts about one project on one machine. It is the wrong place for a decision and its rationale, a trap that another agent in another repo will hit, or a conclusion you reached in conversation. Those are relations between concepts, not lines, and a flat file loses the relation.

The graph layer holds exactly those. A learnings graph records what an agent learned operating in a project: where things live, traps, conventions, decisions with their reasons. An insight graph records what you realized in a session, as timestamped statements that link at least two concepts. It is read the way MEMORY.md is loaded, at the start of a task, but through a tool call rather than a file, so it has no 200-line cap and no machine boundary, and a stale statement is replaced with update_statements instead of being dropped from an index. The AI memory stack page walks through all five layers; the short version is that each layer answers a different question, and mixing them is how memory files turn into noise.

Claude Code Persistent Memory Across Sessions and Machines

Claude Code persistent memory across sessions is native: CLAUDE.md and auto memory survive every restart. Across machines and clients it is not. The memory directory stays on the laptop that created it, and Cursor or Claude Desktop have no way to read it. To get one memory that every session and every client shares, connect an MCP server that stores the memory in a place all of them can reach.

The InfraNodus MCP server does this with graphs in your own account. Two tools carry the insight layer: memory_add_relations saves timestamped statements with [[wikilinked]] concepts, and memory_get_relations recalls them. Two more carry the learnings layer: get_project_learnings reads the learn-<project> graph at the start of a substantive task, and add_project_learnings proposes new entries at the end, shown to you before anything is saved. A short CLAUDE.md block is the hinge between the two layers: a file rule that tells Claude when to reach for the server, and which tool to use when it does:

## Project Memory (InfraNodus MCP)

- **`learn-<project>`** (agent learnings): at the start of a substantive
  task, call `get_project_learnings` with the task as prompt; at the end,
  propose new traps / decisions / workflows via `add_project_learnings`
  and show the batch for approval.

- **`<project>-insights`** (insight memory): at the end of a session,
  distill the USER's new realizations into short relational statements,
  each with at least two `[[wikilinked]]` entities and an ISO 8601
  timestamp; save on the user's OK via `memory_add_relations`.

The same graph is then read from Claude Code on your laptop, from Claude Code on the server, from Cursor, from Claude Desktop, from OpenClaw, and in the InfraNodus web app, because the memory lives in the account, not in a client. Auto memory keeps doing its job for the machine-local facts; the graph takes the relations. The Project Learnings skill installs the learnings half of this loop, with the consent step built in: it never writes without showing you the batch.

Claude Code Memory Plugins and MCP Servers Compared

The InfraNodus MCP server is one of several ways to add that third layer, so it is worth seeing the field. Claude Code memory plugins and MCP servers differ on four things: where the memory lives, who can read it, whether a human can read and edit it, and whether it shows the structure of what was stored. Vendors sell retrieval; none shows what the agent learned or where the holes are.

Claude Code memory plugin: what the options do

A Claude Code memory plugin adds capture and recall around the native files. Claude-Mem captures observations through five lifecycle hooks, summarizes each session, and injects the last ten sessions at start. Mem0 installs from the plugin marketplace with an MCP server, hooks, and a rubric that tells the agent when to search; memories sit on Mem0's platform. Both are good at retrieval. Neither gives you a map of what was stored, so you cannot see which lessons cluster, which contradict, or which are missing.

Claude Code memory MCP: which server for which job

A Claude Code memory MCP server is any server the client can call for storing and recalling. The official @modelcontextprotocol/server-memory keeps a local knowledge graph in one JSONL file, with create_entities, create_relations, and search_nodes. It is the right choice for a single machine and no analysis. The InfraNodus MCP server keeps the graph in your account, with the same relational model plus the analysis layer: clusters, central concepts, and the gaps between clusters, visible in the web app and queryable from any client.

See What Claude Code Has Actually Learned

Storage was the easy half. What follows is the part none of the tools above do. Open the learn-<project> graph in InfraNodus and you see the learnings as a network: every statement becomes connected concepts, and concepts that occur together form topical clusters. In most repos one cluster is the build and restart loop and another is the traps. The size of a node is its betweenness centrality, which says how much of the agent's knowledge routes through it.

Select a cluster to inspect the statements behind it, the way you would read a chapter. Then remove the top nodes: the graph re-forms around what was underneath, and smaller clusters appear, the lessons Claude learned once and never connected to anything. Then open the content gaps. A gap is two clusters with no statement bridging them, and in a learnings graph that is the precise shape of a rediscovery: the agent knows the deploy routine and knows the caching rule, but has never recorded that one breaks the other, so it falls into it again.

This is where the feedback memories earn their keep. A correction is noise until it becomes a statement inside a cluster: stored as a line, it is recalled; stored as a relation, it can be seen next to the decision it should have changed. The densest cluster in most learnings graphs is the one you corrected most often, and the decisions sit at the edges, unconnected to it. Auto memory remembers; the graph shows where remembering was not enough.

Ask an LLM how to judge memory quality and it answers: check whether Claude repeats questions already answered. The graph is that check made visible: a question asked twice is a statement that never joined a cluster, and a gap is a pair of answers that were never connected. Ask AI Insights a follow-up on the selected gap ("what rule would connect these?"), save the answer to Project Notes, and write the one-line rule into CLAUDE.md. The graph showed what the files were missing, and the files get shorter and more current because of it. The same tools answer the other question this persona asks, which MCP server can find gaps in a codebase or its docs: run the /infranodus skill on the repo and compare the code graph with the learnings graph.

Set Up Claude Code Memory with a Knowledge Graph

1. Create an account

Create a free InfraNodus account and copy the API key from the settings.

2. Add the MCP server to Claude Code

One command, user scope, so every project on the machine gets it:

claude mcp add infranodus -s user \
  -- env INFRANODUS_API_KEY=YOUR_KEY npx -y infranodus-mcp-server

The Claude Code setup page has the JSON form for .mcp.json and the remote connector.

3. Install the skill and register the project

Run the /infranodus skill in the repo with --register-project --with-memory. It writes the CLAUDE.md block above, builds the content graphs of the repo, and offers to enable the learnings graph. Or install only the Project Learnings skill if you want the learnings loop and nothing else.

4. Run one real task and approve the first batch

Give Claude Code a substantive task. At the end it proposes two or three learnings and asks "Save these?". Each one is an answer to a question Claude had to ask during the task; approve it and the next session will not ask again. Edit or drop the rest. Nothing is written without that step.

5. Open the graph and move one rule into CLAUDE.md

After a few sessions, open learn-<project> in the web app, read the clusters, open the gaps, and take the one rule that would have saved the most rediscoveries into CLAUDE.md.

Get Started with Graph Memory

https://mcp.infranodus.com

https://mcp.infranodus.com

claude mcp add infranodus -s user --transport http https://mcp.infranodus.com/mcp

{
  "mcpServers": {
    "infranodus": {
      "url": "https://mcp.infranodus.com"
    }
  }
}

codex mcp add infranodus --url https://mcp.infranodus.com
codex mcp login infranodus

{
  "mcpServers": {
    "infranodus": {
      "command": "npx",
      "args": ["-y", "infranodus-mcp-server"],
      "env": {
        "INFRANODUS_API_KEY": "your-api-key"
      }
    }
  }
}

/plugin marketplace add infranodus/skills
/plugin install project-learnings@infranodus-skills

npx skills add infranodus/skills --skill project-learnings -g -a claude-code -y

$skill-installer install the project-learnings skill from https://github.com/infranodus/skills

npx skills add infranodus/skills --skill project-learnings -g -a codex -y

npx skills add infranodus/skills --skill project-learnings -g

Frequently Asked Questions

Give Claude Code a Memory You Can See

Connect the MCP server, run one task, and open the graph: the clusters of what Claude learned about your project, the concepts that connect them, and the gaps between them.