The CLAUDE.md Memory Hierarchy

CLAUDE.md files are plain-markdown instructions Claude Code loads at the start of every session. They are context, not enforced configuration — for hard enforcement you use a hook or a permission rule, not CLAUDE.md. The architect's job is to know which files load and in what order, because order determines precedence when instructions conflict.

The four scopes (broad → specific)

Files are loaded in load order from broadest to most specific, and all discovered files are concatenated, not overridden. Managed policy loads first, then user, then project, then local. Because content closer to where you launched Claude is read last, the most specific instruction effectively "wins" when two conflict.

Walking up the directory tree

Claude Code also walks up the directory tree from your working directory. If you launch in foo/bar/, it loads foo/CLAUDE.md then foo/bar/CLAUDE.md (root-down ordering), and within each directory CLAUDE.local.md is appended after CLAUDE.md. Subdirectory CLAUDE.md files below your launch point are not loaded at launch — they load on demand when Claude reads a file in that subdirectory.

Operating the hierarchy

• Run /init to generate a starting project CLAUDE.md from your codebase; if one exists it suggests improvements instead of overwriting.
• Run /memory to see exactly which CLAUDE.md, CLAUDE.local.md, and rules files are loaded this session — your first debugging step when an instruction "isn't being followed."
• Keep each file under ~200 lines. CLAUDE.md is loaded in full every session and consumes tokens; long files reduce adherence. (Auto memory's MEMORY.md, by contrast, is capped at the first 200 lines / 25KB.)
• In monorepos, use claudeMdExcludes (a settings glob array) to skip other teams' ancestor files — but managed policy CLAUDE.md can never be excluded.

Why precedence matters on the exam

A common question gives you a personal rule in ~/.claude/CLAUDE.md and a conflicting project rule in ./CLAUDE.md, then asks which applies. Answer: both load, but the project file is read after the user file, so the more specific project instruction takes precedence. Managed policy always loads first and outranks individual exclusion.

Exam focus: Memorize the four scopes and their load order (managed → user → project → local) and that files are concatenated, not overridden. Know that more-specific / later-loaded instructions win conflicts, that ancestor files load at launch while subdirectory files load on demand, and that /init bootstraps and /memory audits the loaded set. CLAUDE.md is context; use hooks when you need deterministic enforcement.