Claude Code, Codex, and Cursor users compare AGENTS.md and CLAUDE.md memory files
Threads across Cursor and Claude communities converged on the same session-amnesia toolkit: AGENTS.md or CLAUDE.md files, scoped plans, scaffold prompts, and tighter workflow boundaries. Teams should duplicate project context across tools for now, since Claude Code, Codex, and Cursor still read different memory surfaces.

TL;DR
- Across taimoorkhan10's Cursor thread, the matching ClaudeCode post, and the ClaudeAI repost, users described the same failure mode: each coding tool forgets project conventions between sessions, and each tool wants that context in a different place.
- Anthropic's Claude Code memory docs say Claude reads
CLAUDE.mdplus auto-written memory at session start, while OpenAI's Codex AGENTS.md guide says Codex builds an instruction chain fromAGENTS.mdfiles before doing any work. - Cursor's rules docs add a third surface:
.cursor/rules/*.mdcfor scoped project rules, though Cursor explicitly says plain markdown users should useAGENTS.mdinstead. - Community replies around mattrickard's AGENTS.index.md idea, theo's standard gripe, and the comment threads under the ClaudeCode discussion converged on the same workaround: keep one canonical memory file or sync layer, then fan it out into whatever each agent actually reads.
- New tools are already shipping around that gap. AlphaSignalAI's Watchmen post points to a local repo that auto-generates
CLAUDE.mdandAGENTS.md, while Headroom claims to mine failed sessions and write corrections back into both files.
You can compare Anthropic's memory model, OpenAI's AGENTS.md chain, and Cursor's rule system side by side now. The weird part is how much of the ecosystem is already building around the mismatch: Watchmen writes cross-agent briefs automatically, Headroom pitches shared memory plus CLAUDE.md and AGENTS.md updates, and mattrickard is sketching an AGENTS.index.md layer just to keep subfolder rules sane.
Session amnesia
I got tired of explaining my project to every AI coding tool every single session. Building the open source fix.
11 comments
I got tired of explaining my project to every AI coding tool every single session. Building the open source fix.
26 comments
The core complaint was not that memory files do nothing. It was that they only work inside their own harness. In replies under the ClaudeCode thread, taimoorkhan10 said CLAUDE.md solves Claude Code only, while Codex and Cursor still need their own formats or rule surfaces.
That is why the comment sections quickly shifted from "use a markdown file" to arguments about portability. Under the Cursor thread, one reply said a claude.md file works fine inside Cursor, while another suggested AGENTS.md plus a skills file. Under the ClaudeAI repost, a commenter linked Anthropic's docs, but the original poster repeated the same cross-tool objection.
CLAUDE.md, AGENTS.md, and Cursor rules
The product docs now make the split pretty explicit:
- Anthropic's Claude Code memory docs say
CLAUDE.mdfiles are user-written instructions, while auto memory stores learned patterns. Both load at the start of every conversation. - OpenAI's Codex AGENTS.md guide says Codex reads
AGENTS.mdbefore work starts, with a precedence chain that begins in~/.codexand then walks from project root down to the current directory. - Cursor's rules docs say project rules live in
.cursor/rulesas.mdcfiles with path scoping and frontmatter. The same page adds one notable line: if you want plain markdown, useAGENTS.mdinstead.
That is the whole argument in one screenshotless sentence. Claude has its own native file, Codex has an open-format file, and Cursor supports both its own richer rule format and a plain markdown fallback.
The community response has been to treat AGENTS.md as the portable denominator, then shim Claude around it. In replies under the ClaudeCode thread, one commenter suggested putting shared instructions in AGENTS.md and adding a minimal CLAUDE.md that references it.
Scaffolds, plans, and workflow boundaries
how Claude Code accelerated my game dev process [completed in ~30 mins]
0 comments
Who could say no to Workflow?
0 comments
Once the thread moved past file names, users started describing what actually belongs in those files and prompts.
- Complex_Tie_4875 said Claude Code works better with a scaffold for the project plus a reference app or site, which reduces UI back-and-forth.
- In the comments under the ClaudeCode thread, Veei described a heavier setup: keep architecture and gotchas in
claude.md, generate plans for long features, then feed Claude a session-specific prompt that begins by reading the plan and the repo. - Stevekaplanai posted the flip side. A large workflow for a 58-page audit looked great in proposal form, then burned through the week's remaining tokens.
- Anthropic's skills docs draw the same boundary in product terms: factual standing guidance belongs in
CLAUDE.md, while multi-step procedures should move into skills that load only when invoked.
That combination, short standing context plus explicit plan files plus narrower workflows, is the closest thing these threads had to consensus.
Sync layers and generated briefs
The more interesting shift is that people are already building tooling on top of the markdown-file era instead of waiting for vendors to agree.
Watchmen, the repo linked from AlphaSignalAI's repo follow-up, says it watches sessions from Claude Code, Codex, and pi.dev, then writes skill bundles plus synchronized workspace briefs in CLAUDE.md and AGENTS.md. Headroom, linked from AlphaSignalAI's Headroom post, makes a related pitch from the token side: shared cross-agent memory, local reversible compression, and a headroom learn command that writes corrections back into those same files.
mattrickard's post pushes the same idea down a level. Instead of hand-maintaining overlapping AGENTS.md files in every subfolder, keep one AGENTS.index.md whose headings mirror the folder tree, then generate the minimal slice each folder needs.
By this point the debate is not really CLAUDE.md versus AGENTS.md. It is whether teams keep hand-authoring agent context at all, or start generating and syncing it as another repo artifact.
Worktrees became part of the memory problem
I noticed a workflow issue where when using `claude agents` and having multiple changes happening in a repo at the same time, observing them was difficult. I fixed that problem with claude-swap
0 comments
One late thread added a separate wrinkle: even when an agent has the right context, parallel worktrees can hide the actual work from the main checkout.
In LongAerie4580's ClaudeCode post, claude-swap uses fswatch and rsync to live-sync changed files from a Claude --worktree copy back into the main repo so a dev server hot-reloads instantly. The pitch was blunt: no hooks, no CLAUDE.md, no agent-side config.
That is a different class of memory surface. The agent may know the project rules, but the human still needs the working tree, preview server, and terminal layout to stay in sync while multiple background agents edit isolated copies of the repo.