CLAUDE.md vs auto memory: Claude Code's two memories, split by who writes them

The starting point for both mechanisms is the same problem: Claude Code begins every session from a blank state, so anything carried over has to be loaded again at the start. The article splits that load into two boxes by asking who does the writing. CLAUDE.md is Markdown the user maintains, and where it sits changes who sees it — a fixed OS-level path holds organization-wide rules, ~/.claude/CLAUDE.md holds one person's preferences across every project, ./CLAUDE.md or ./.claude/CLAUDE.md in the working directory holds team-shared policy under version control, and ./CLAUDE.local.md holds one person's project-specific settings. Files in the working directory and its parent levels load together at startup, while anything in subdirectories is pulled in only when Claude reads a file there.

auto memory works from the other direction. Rather than waiting for instructions, Claude notes down what it judges worth keeping, sorted into four kinds: the user's role and preferences, corrections and confirmed approaches, project decisions that code and git history do not reveal, and pointers to outside references such as issue trackers or dashboards. Anything readable from the code, or already written in CLAUDE.md, is left out. Its index, MEMORY.md, is read every session, but because that file has limits, the design pushes detail into separate topic files and keeps the index short.

The practical friction sits in that difference. The article notes CLAUDE.md arrives as a message at the beginning of a conversation rather than as an enforced rule, so its effectiveness depends on how it is written — concrete and checkable, roughly 200 lines, and free of contradictions, since conflicting instructions leave Claude's choice unsettled. The test of whether the split is working may be simply how often the same correction gets typed twice; on the second time, it is likely a candidate for CLAUDE.md rather than something left to auto memory to absorb.