Skip to content
Home › Claude Code Configuration & Workflows

CLAUDE.md Hierarchy

Claude Code Configuration & Workflows

Definition

The set of memory files Claude Code loads and concatenates (broad→specific) into the context as instructions, spanning managed, user, project, and local scopes.

Key points

  • Load order, broad→specific (all concatenated, not overriding): Managed policy (/etc/claude-code/CLAUDE.md on Linux) → User ~/.claude/CLAUDE.md → Project ./CLAUDE.md or ./.claude/CLAUDE.md → Local ./CLAUDE.local.md.
  • Parent directories are read before child; CLAUDE.local.md is read after CLAUDE.md. Managed policy cannot be excluded.
  • CLAUDE.md content is delivered as a user message, not enforced config — it is probabilistic guidance, not a hard gate.
  • Path-scoped .claude/rules/*.md with paths: frontmatter globs apply only under matching paths; user rules load before project rules, so project wins.
  • Hot-reload vs restart: memory files are re-read when changed (and via /memory), unlike model/outputStyle which need a restart.
  • AGENTS.md is not read directly — reference it from a CLAUDE.md via @AGENTS.md. See CLAUDE.md Imports And Rules.

Why it matters for the exam

  • D3 (20% of scored content) tests where org-wide vs personal vs project instructions live and that all layers are concatenated rather than one overriding another.
  • Distinguishes CLAUDE.md (soft, probabilistic memory) from permissions and hooks (hard config).

Common gotchas

  • CLAUDE.md is probabilistic (delivered as a user message) → for hard enforcement of financial/destructive ops use a PreToolUse hook, never CLAUDE.md alone. See PreToolUse hook enforcement.
  • Org-wide memory can only be injected via claudeMd in managed settings.
  • Managed policy layer cannot be excluded by claudeMdExcludes.

See also

Sources

Referenced by