CLAUDE.md and the Settings Hierarchy

Claude Code is configured through two parallel systems. Memory files (CLAUDE.md and rules) are natural-language instructions the model reads at the start of a session. Settings files (settings.json) are JSON that the harness enforces: permissions, hooks, environment variables, model choice. Both systems are layered across user, project and enterprise scopes, and the exam tests which layer wins and what belongs where.

Memory files

CLAUDE.md is loaded into context automatically. Claude Code looks in several places:

Location	Scope	Shared?
Enterprise managed path (OS-specific system directory)	Organisation	Deployed by IT
~/.claude/CLAUDE.md	User, every project	No
./CLAUDE.md or ./.claude/CLAUDE.md	Project	Yes, commit it
./CLAUDE.local.md	Project, this machine	No, gitignore it
CLAUDE.md in parent directories	Monorepo roots	Yes
CLAUDE.md in subdirectories	Loaded on demand when Claude works with files there	Yes

Files from the current directory up to the root are loaded at launch; subdirectory files load lazily, which keeps a monorepo's context cost proportional to what is touched. A CLAUDE.md can pull in other files with @path/to/file imports, so a long architecture document can live elsewhere and be referenced. /init generates a starting CLAUDE.md from the repository; /memory opens the memory files for editing; # at the start of a message adds an instruction to memory quickly.

The .claude/rules/ directory holds additional Markdown rule files that are loaded alongside CLAUDE.md. A rule file can carry a paths frontmatter field with glob patterns so that it applies only when Claude is working on matching files, which is the right tool for "when editing SQL migrations, always..." instructions without burdening every session.

Good CLAUDE.md content is short, specific and operational: build and test commands, naming conventions, architectural boundaries, things the model gets wrong in this repository. Bad content is generic advice, long prose, or anything the harness should enforce instead (put "never run git push --force" in a deny rule, not in prose).

Settings files

Settings are JSON and are merged across scopes:

File	Scope	Purpose
Managed settings (OS system path)	Enterprise	Policies users cannot override
~/.claude/settings.json	User	Personal defaults across projects
.claude/settings.json	Project, shared	Team configuration, committed
.claude/settings.local.json	Project, personal	Local overrides, auto-gitignored

Precedence from highest to lowest: enterprise managed settings, command-line arguments, local project settings, shared project settings, user settings. Arrays such as permission allow lists are combined across scopes; scalar values are overridden by the higher-precedence scope. Enterprise policy sits above everything, including command-line flags, which is how an organisation can forbid bypassPermissions mode or pin a hook that users cannot remove.

A representative project settings file:

{
  "permissions": {
    "allow": ["Bash(npm run test:*)", "Read(./docs/**)"],
    "deny": ["Read(./.env)", "Bash(git push:*)"],
    "defaultMode": "acceptEdits"
  },
  "env": { "NODE_ENV": "test" },
  "hooks": {
    "PostToolUse": [{ "matcher": "Edit|Write",
      "hooks": [{ "type": "command", "command": "npx prettier --write \"$CLAUDE_FILE_PATHS\"" }] }]
  },
  "enableAllProjectMcpServers": false
}

Other commonly tested keys: model (default model for the project), env (variables exported to every tool execution), apiKeyHelper (a script that returns a credential), cleanupPeriodDays (transcript retention), includeCoAuthoredBy (commit trailer), sandbox (filesystem and network isolation for Bash), and the MCP approval keys enableAllProjectMcpServers, enabledMcpjsonServers and disabledMcpjsonServers.

Deciding where something goes

You want to...	Put it in
Tell Claude how the project builds	CLAUDE.md (project)
Apply a convention only to one directory	.claude/rules/*.md with paths, or a subdirectory CLAUDE.md
Forbid a command for the whole team	.claude/settings.json permissions.deny
Forbid it for the whole company	Managed settings
Set a personal preference everywhere	~/.claude/settings.json or ~/.claude/CLAUDE.md
Try an allow rule without committing it	.claude/settings.local.json

A useful distinction for the exam: memory files influence the model; settings files bind the harness. Anything safety-relevant belongs in settings.

Exam focus

• CLAUDE.md is loaded from enterprise, user, project (and parent directories) at launch; subdirectory files load on demand; CLAUDE.local.md is personal and gitignored.
• @file imports let a memory file reference other documents; .claude/rules/ files can be scoped by paths globs.
• Settings precedence: managed (enterprise) > command line > settings.local.json > settings.json > user settings.
• Permission arrays merge across scopes; scalars are overridden by the higher scope.
• Enterprise managed settings cannot be overridden by users or by command-line flags.
• Memory files guide the model; settings files enforce behaviour. Safety constraints go in settings.