CLAUDE.md and the Memory Hierarchy

How CLAUDE.md files at different scopes combine into Claude Code's context, and why merging is not overriding.

Claude Code·Lesson 1 of 6·7 min

CLAUDE.md is a memory file that Claude Code automatically loads into context at the start of a session, without you having to reference it manually. It typically documents project conventions, build and test commands, architectural constraints, and anything else you want Claude to "just know" every time it works in a given codebase. Think of it as persistent, always-on context, distinct from a one-off prompt you type into the session.

The exam tests one mechanic here more than any other: the memory hierarchy. Claude Code looks for CLAUDE.md files at multiple scopes, and it loads all of them into context simultaneously.

The four scopes

Enterprise: organization-wide policy, managed centrally, applies to every user and every project.
User: personal preferences that follow you across all projects on your machine (for example, "always write commit messages in imperative mood").
Project: checked into the repository, shared with every teammate who clones it (build commands, coding conventions, directory layout notes).
Local: project-specific but not committed, for your own private notes or machine-specific paths.

The critical fact: these four scopes are merged, not layered as overrides. A more specific file (say, project-level) does not replace or override what an enterprise-level or user-level CLAUDE.md says. It adds to it. All applicable CLAUDE.md content ends up concatenated into Claude's context. There is no precedence resolution where the closest file "wins" and discards the others.

This matters practically. If your enterprise CLAUDE.md says "never commit directly to main," and your project CLAUDE.md doesn't mention branching at all, that enterprise rule is still active in every session inside that project. You cannot silently override an inherited instruction just by staying quiet about it at a lower scope. If you want to change behavior at a lower scope, you have to say so explicitly, and even then both instructions are present in context — good CLAUDE.md authoring means avoiding direct contradictions between scopes, because Claude has to reconcile conflicting text, not automatically prefer the more specific file.

Exam trap Watch for answer choices that describe the hierarchy in override language: "the project CLAUDE.md overrides the user CLAUDE.md," or "local settings take precedence over and replace project settings." This is the single most common wrong-answer pattern in this domain. The correct mental model is additive merging across scopes, not a cascade where specificity wins. If an option uses the word "overrides" or "replaces" to describe CLAUDE.md scope interaction, it is almost certainly the distractor.

What belongs in CLAUDE.md

Good candidates: the exact commands to run tests and linters, naming conventions, directory structure explanations, known gotchas ("this repo uses a custom bundler, do not add webpack config"), and pointers to other docs. Bad candidates: anything that changes frequently, secrets, or content so long it crowds out useful context on every single session — CLAUDE.md content is loaded every time, so it has a real token cost.

Scenario: A team has an enterprise CLAUDE.md requiring "all database migrations must be reviewed by a DBA before merging." An engineer, annoyed by this on a low-stakes internal tool, adds a line to the project-level CLAUDE.md saying "DBA review is not required for this repo." What happens? Both instructions are merged into context — Claude sees the conflicting statements together, and behavior becomes unreliable/ambiguous rather than cleanly resolved in favor of the project file. The reasoning: since scopes merge rather than override, the engineer's fix does not work as intended; the enterprise rule was never designed to be locally revoked this way, and if the org wants an exception mechanism, it needs to be built into the enterprise policy itself, not fought at the project level.

Ordering within the merge

Because content from every applicable scope lands in context together, the practical question shifts from "which one wins" to "in what order does Claude read them, and does that create emphasis." Claude Code has a defined load order across scopes, but that order affects how instructions are sequenced in context, not which ones are honored. Do not confuse load order with precedence — the exam is testing whether you understand that later-loaded content does not overwrite earlier-loaded content; it accumulates alongside it. If two CLAUDE.md files genuinely disagree, you have an authoring problem, not a resolved conflict, and the fix is to edit the conflicting file, not to rely on scope order to silently pick a winner.

Try it

In an existing project, run claude and check whether a CLAUDE.md exists at the project root. If not, create one with your test command and one architectural note. Then check your home directory for a user-level CLAUDE.md (or create one with a personal preference like your preferred commit message format). Start a new session in that project and ask Claude to state what it knows about the project's conventions — confirm both the project and user content show up together.