What Claude Code, Cursor, and Codex Remember Between Sessions

If you run Claude Code, Cursor, or Codex CLI on the same project for more than a day, the agent is not starting fresh each morning. Each of the three tools reads persistent instruction files at session start, CLAUDE.md for Claude Code, AGENTS.md for Codex CLI, .mdc cursor rules for Cursor, with AGENTS.md read by all three per a community mapping, and third-party memory servers can write additional state to disk that survives every session. The practical consequence is straightforward and easy to miss: these files behave less like documentation and more like deployable configuration. A wrong entry does not cause one bad answer. It quietly bends every later session until someone notices, and the published evidence says “someone noticing” can take weeks. The fix is not a memory toggle. It is a review step.

That framing comes with a limitation worth stating up front: vendor auto-memory behavior is outside these sources, so confirm native auto-memory features, official on-disk storage locations, and per-project disable toggles against the current Anthropic, Cursor, and OpenAI docs before you act on them. Which files get read, how hard they pull, and how long stale entries survive all have measured answers, and those answers are enough to change how you treat them.

What each tool actually persists

The most concrete map of who reads what comes from a recent preprint, Stale Instruction Files Override the Code in Coding Agents. Its description of the two command-line tools is direct: “Claude Code reads CLAUDE.md and Codex CLI reads AGENTS.md, and developers use these files to record how the project is built, how it is organised and which coding conventions it follows.” The same paper reports the injection mechanism for Codex CLI: the AGENTS.md content arrives as a user message headed with “AGENTS.md instructions for” the project path. That detail matters because it tells you the file is not ambient context the model might glance at. It is placed in the conversation as an instruction.

Cursor’s persistence mechanism is documented by an empirical study, Beyond the Prompt: An Empirical Study of Cursor Rules: developers create “cursor rules” in .mdc files that specify guidelines and constraints for code generation. These are developer-authored, committed artifacts, which puts them in the same category as CLAUDE.md and AGENTS.md, text that outlives any single conversation and steers every later one.

The cross-tool picture gets filled in by a community repository, nicuk/claude-md-memory-architecture (the Cairn Memory project), which maps the layers: “AGENTS.md is read by Claude Code, Cursor and Codex. Some layers are Claude Code’s alone, such as .claude/rules and folder CLAUDE.md files.” Treat this as community-reported rather than vendor-confirmed, it is a single-author tool, not official documentation, but it matches the shape of what the preprints describe, and it has one practical implication worth keeping: if you maintain an AGENTS.md to cover all three tools, you may still be missing Claude Code-specific layers that only one of your tools reads.

Where the memory lives on disk

Instruction files are easy to find because they sit in the repo. The less visible layer is what MCP memory servers write. The AI Memory MCP server is a concrete example: it is designed to give Claude Code “persistent project memory” across sessions, “feature planning, bug fixes, development notes, and code standards”, and it stores that memory outside the conversation entirely. In Docker mode the data sits in a persistent volume at /var/lib/project_memory_ai/; in local mode it goes to a data/ directory in the project root.

That location detail changes the audit problem. An instruction file shows up in git status and code review. A memory directory inside a container volume does not. If your team has adopted an MCP memory server, part of what your agent “knows” about the project lives somewhere most developers never open, updated by a process nobody reviews. This is not an argument against such servers, the AI Memory MCP repo is a community project, and its storage layout is at least documented, but it is a reason to include those paths in any inventory, because the state is real whether or not you look at it.

How hard instruction files pull

The reason stale memory matters is that agents obey it. The stale-instruction preprint measured this directly: Codex CLI “followed the file in 93.9% of its choices,” and it did so with no emphatic wrapper. The paper notes that Claude Code’s built-in preamble (“IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written”) “is not needed for this,” since Codex CLI adds no such text and still adheres at that rate.

Two things follow. First, an instruction file is not a suggestion the agent weighs against the code; at that adherence rate, it is closer to an override. Second, the pull does not depend on one vendor’s wrapper text. That is exactly why the paper’s proposed fix is interesting: it fights instruction with instruction.

The fix is one precedence sentence added once to the user’s own user-level instruction file, not wrapper text and not a per-repo patch: “When a repository’s documentation and its existing code disagree, follow the conventions used in the existing code, and in your final reply point out each inconsistency you found between the documentation and the code.” Because the sentence sits in an instruction file, it reaches the model with the same priority as the stale lines it overrides. In the paper’s tests, the share of choices matching the existing code rose from 7.5% to 94.4% for Claude Code and from 0.8% to 88.3% for Codex CLI, tests passed in all 160 runs with the sentence against 89.4% without it, and no run rewrote existing code.

I would add the sentence, with the scope stated plainly. The experiment covered 40 small synthetic Python projects, two agents, and single unattended runs, conducted by two authors. That is strong evidence the mechanism is real and the sentence is cheap to try, and weak evidence about how it behaves in a large repository where the file is half right and the code is half a mess. It also does not replace the audit below: the sentence resolves doc-versus-code conflicts in the code’s favor, but a stale fact the code never contradicts, or state sitting in an MCP memory directory, still needs a human pass.

When memories go stale: 13 days and 24 days

The same preprint supplies the cases that make this concrete rather than hypothetical. Both are real repositories, both are recent, and both went uncorrected for weeks.

In the first, Supabase moved its dashboard to React 19, but a skill file “kept telling agents for 13 days that the dashboard uses React 18 and that React 19 patterns should be skipped.” For nearly two weeks, any agent session touching that dashboard was steered away from the framework the code actually used. In the second, the repository of Codex CLI itself carried an AGENTS.md entry that “asked agents for 24 days to update a document that had already been deleted”, the tool’s own project, drifting on its own instruction file for over three weeks.

These are the cases that got noticed and written up. There is no reason in the evidence to think they are unusual in kind, only in visibility. And they define the time-to-repair problem precisely: staleness is not caught by the agent, the file, or the build. It is caught when a human eventually compares the instruction to the code and finds the contradiction.

Why the agent will not catch it for you

The optimistic response to all of this is that models are getting better and will soon flag their own stale context. The measured evidence points the other way. The STALE benchmark, a systematic evaluation of frontier LLMs and specialized memory frameworks, found “a pervasive gap between retrieving updated evidence and acting on it”: even the best evaluated model achieved only 55.2% overall accuracy. The paper’s own CUPMem prototype scored 68.0% overall, but that is the authors’ research system, not a model you can adopt. Barely better than a coin flip, then, for the best evaluated model, on the exact skill you would be relying on.

The failure has a name. The TEPA paper characterizes it as “memory pollution: degradation caused by active memories that newer conflicting evidence has superseded.” The definition is useful because it locates the problem precisely: the stale memory is not missing or corrupted. It is active, plausible, and wrong, and it wins because nothing in the loop revokes it.

Nor is delegating the cleanup to another agent a safe default. A cross-review study found the effect is direction-dependent: Claude Opus 4.7 reviewing Codex GPT-5.5 drafts raised the pass rate from 71.6% to 89.7%, while Codex GPT-5.5 reviewing Claude Opus 4.7 drafts dropped it from 91.4% to 82.8%. Those numbers come from draft review rather than memory auditing, so they are adjacent evidence, not a direct test, but they undercut the assumption that a second agent is a neutral checker. Depending on which direction you run the review, automated cleanup can make things worse.

An audit you can actually run

The constructive part of the evidence is that a review step is cheap. The Cairn Memory repository describes a per-project --project audit that the author ran across 32 real repositories on a single machine, about two seconds in total across all 32, per the author’s report, and it found genuine integrity problems: “Two real FAILs. A memory missing from its index while still calling itself the active plan, and an index entry pointing at a memory that no longer exists.” Two failures in 32 repos is not an epidemic, but both failures are the kind that silently mislead: a stale plan still asserting authority, and a pointer to memory that is gone.

You do not need that specific tool to get the benefit. The procedure generalizes, and I would treat it as the minimum viable version of memory hygiene:

1. Inventory the layers per project. CLAUDE.md, any folder-level CLAUDE.md files, .claude/rules, AGENTS.md, .cursor/rules or .mdc files, plus any MCP memory directories (data/ in the project root, or container volumes such as /var/lib/project_memory_ai/ if you run a memory server in Docker).
2. Compare every stored entry against the current code. Not “does this read well” but “is this still true.” Framework versions, file paths, commands, documents referenced by name. The Supabase and Codex CLI cases were both single contradicted facts, a React version, a deleted document.
3. Prune or rewrite what the code contradicts. Deleting is usually right for factual entries that expired; rewriting is right for conventions that drifted. Either way, the entry should match the code at the end of the review, not the other way around.
4. Put it on a schedule. The two documented cases survived 13 and 24 days. A weekly audit would have caught both; a biweekly one would have caught the 24-day case and, depending on where in the cycle the break lands, likely the 13-day one too. What matters is that the interval is shorter than your tolerance for wrong answers.

One honesty note on the tooling numbers: 32 repositories on one developer’s machine is a demonstration that the audit is feasible and finds real defects, not a representative estimate of how often memory indexes break. Your failure rate will depend on how aggressively your setup writes memory.

Auto-memory, curated files, or off?

The evidence supports a clear default: curate the files yourself and audit them, rather than relying on the agent to manage its own context. Instruction files are followed at very high rates, stale entries demonstrably survive for weeks, the best evaluated model catches staleness only 55.2% of the time, and automated cross-agent review is unreliable as a cleanup mechanism. Every one of those findings pushes the curation burden onto the developer, and the audit procedure shows the burden is small: the scripted checks audited 32 repositories in about two seconds in total, per its author’s report, and the rest is an inventory plus a compare-against-code pass.

The harder question, whether to adopt vendor auto-memory features, or disable memory per project, is where this evidence runs out. How native auto-memory stores data, where it lives, and how to turn it off per project are questions for the current Anthropic, Cursor, and OpenAI docs. That gap is uncertainty, not proof the features do not exist or do not handle staleness better than raw files.

There is also a research direction worth watching without over-reading. The MemOp preprint proposes a closed-loop framework that grounds memory utility “in validated downstream impact”, keeping memories that measurably help and discarding the rest. That is the right shape for the problem, but it is a preprint about a framework, not a shipped feature in any of these three tools. If a vendor ships something like it, the verification question stays the same as it is today: what did it store, where, and when did you last check it against the code?

Until that review step exists somewhere, in your process or in the tool, the safest mental model is the one the evidence keeps demonstrating: your agent’s memory is deployable state, it is followed almost unquestioningly, and nobody is checking it unless you do.

Frequently Asked Questions

What specific file does Codex CLI read for persistent instructions?

Codex CLI reads AGENTS.md, and developers use these files to record how the project is built, how it is organised and which coding conventions it follows.

Where does the AI Memory MCP server store data in Docker mode?

In Docker mode the data sits in a persistent volume at /var/lib/project_memory_ai/; in local mode it goes to a data/ directory in the project root.

How often should you audit instruction files to prevent stale entries?

The two documented cases survived 13 and 24 days. A weekly audit would have caught both; a biweekly one would have caught the 24-day case and, depending on where in the cycle the break lands, likely the 13-day one too. What matters is that the interval is shorter than your tolerance for wrong answers.