Claude Code

Everything in Claude Code configuration comes down to scope. Each mechanism — instructions, settings, rules, skills, agents — exists at several layers, from organisation down to one developer’s machine. The layer you write to decides who receives the setting and what can override it. Learn the layers once, carefully: the exam’s questions here are almost all layer questions in disguise.

How to read this page: the Exam rule callouts collect what the exam expects you to reproduce exactly — file names, orders, flag values — while the prose around them builds the understanding you can re-derive under pressure. Every fact was verified against the official Claude Code documentation at code.claude.com on 3 October 2026, and the Study pointers at the end link the exact pages. Claude Code moves quickly; treat those pages as the living source and this one as the exam-shaped map of it.

01Four homes for instructions

CLAUDE.md is where the instructions you write live. Four locations, four audiences:

• —Managed policy — a CLAUDE.md placed by IT via configuration management at a system path: /Library/Application Support/ClaudeCode/CLAUDE.md on macOS, /etc/claude-code/CLAUDE.md on Linux and WSL, C:\Program Files\ClaudeCode\CLAUDE.md on Windows. Everyone in the organisation gets it.
• —User — ~/.claude/CLAUDE.md. Yours alone, loaded in every project.
• —Project — ./CLAUDE.md or ./.claude/CLAUDE.md, committed to source control. The team’s copy: architecture, standards, workflows.
• —Project-local — ./CLAUDE.local.md, gitignored. Personal details for one project: your sandbox URL, your preferred test data.

Separate from all four sits auto memory — notes Claude writes itself, distilled from your corrections, scoped per repository and shared across worktrees. A session loads at most the first 200 lines or 25 KB of it. That is a cap CLAUDE.md itself does not have.

Two content rules the docs are emphatic about. Write instructions that can be checked: "Run npm test before committing" rather than "test your changes". And know how imports behave. A CLAUDE.md can pull in other files with @path references — but wrapped in backticks or a code fence, the @ is literal text and nothing is imported. No error, no partial load. The import is simply skipped.

02Rules files and path scoping

For teams who would rather not maintain one monolithic file, .claude/rules/ holds modular instruction files — a code-style file, a testing file, a security file — with personal equivalents under ~/.claude/rules/ and shared rule sets often symlinked into the project directory. A rule file can declare paths front-matter — a YAML list or a comma-separated string of globs like src/api/**/*.ts — so it only loads when matching files are in play. And in monorepos, the claudeMdExcludes setting keeps other teams’ CLAUDE.md and rules files out of your sessions.

03AGENTS.md is a fallback, not a companion

The single most-tested fact in this domain: by default, Claude Code reads CLAUDE.md files or AGENTS.md — not both. If a CLAUDE.md, a .claude/CLAUDE.md, or even just a CLAUDE.local.md exists in the working directory or any parent, AGENTS.md is not read. Your personal ~/.claude/CLAUDE.md and the managed policy file do not trigger that suppression — they are not project files — and neither do rules files.

If you genuinely want both, two doors exist: import AGENTS.md from your CLAUDE.md with an @ reference, or change the instructionFiles setting. Know its four values, because the exam can ask which is which. claude-md-or-agents-md is the default — the one-or-the-other behaviour above. claude-md-and-agents-md loads both, CLAUDE.md files first in each directory. claude-md reads CLAUDE.md files only. And managed-only loads just the managed policy file plus auto memory, ignoring user, project and local instructions entirely. One more thing to memorise — the files never read under any configuration: AGENTS.local.md, AGENTS.override.md, and anything under .agents/.

04settings.json: five layers, one chain

Settings — permissions, hooks, environment variables, default model, plugin configuration — live in JSON files with a strict precedence order, highest first:

• —Managed settings — managed-settings.json or MDM policy. Deployed to everyone; nothing the user does overrides it.
• —Command line — --settings, --model and friends. This session only.
• —Project local — .claude/settings.local.json. Yours, this project.
• —Shared project — .claude/settings.json. The team’s, once committed.
• —User — ~/.claude/settings.json. Yours, everywhere.

Merging is key-by-key: a higher layer wins only on the keys it actually sets, and everything else falls through. Three behavioural notes that become questions. First: "don’t ask again" approvals are written by Claude Code itself into the project-local file — which it then gitignores for you the first time, inside a git repo, but only if it did the writing. Create the file by hand and the gitignore is your job. Second: settings files hot-reload mid-session for permissions, hooks and environment variables, but the model setting is read at launch — edit the file and it applies next session. Mid-session, use the commands instead: /model switches model (at some cache cost), /effort changes effort. Third, a trust asymmetry. While settings.local.json stays untracked, its allow rules apply without the workspace trust step — but allow rules from the committed settings.json only take effect for teammates after they trust the folder (deny and ask rules apply immediately either way). Trust the local file to git, and the trust step applies to it too.

Permissions themselves are rule strings: allow entries like Bash(npm run test *) and deny entries like Read(./.env) — the shape the exam expects you to read fluently.

05Guidance or enforcement

The distinction this domain exists to test: a CLAUDE.md — even the managed one — is guidance. It shapes behaviour; it does not technically prevent anything, and "usually followed" is not a security control. Anything that must hold goes into managed settings: permissions.deny to block tools, commands and paths; sandbox settings for isolation; environment and provider routing; login and organisation restrictions. And the docs’ own rule of thumb is worth keeping: if a failure to comply is an inconvenience, CLAUDE.md. If it is an incident, settings.

06What a team commits

The repository-setup question has a clean answer, and it is easier to hold as one picture than as a list. Everything shared lives inside the repository, everything personal stays out of it, and everything organisation-wide sits above both on a machine your team does not control:

07Skills: instructions that load when used

A skill is reusable instructions in a SKILL.md file: project skills in .claude/skills/<name>/ (shared by committing), personal ones in ~/.claude/skills/<name>/, enterprise ones in the managed directory. The difference from CLAUDE.md is when it loads. Only a listing of names and descriptions sits permanently in context — enough for Claude to know what exists — while the body loads when the skill is invoked: by you as /skill-name, or by Claude itself when the conversation matches the description. That is progressive disclosure. It is why long reference material belongs in a skill rather than a CLAUDE.md that is loaded in full every session. And the description front-matter is the trigger — write it to say when to reach for the skill.

Two details worth a question each. A skill body can inject live shell output before Claude reads it — a line like !`git diff HEAD` embeds the current diff into the prompt. And custom slash commands — Markdown files in .claude/commands/ — are the older format: they still work and accept the same front-matter as skills except name and paths, but new work should prefer a skill, whose folder can hold supporting files alongside the SKILL.md.

When one name is defined twice, know the pecking order: enterprise beats personal beats project — yes, the personal skill outranks the project one. A skill beats a command file of the same name; your own skill replaces a bundled command but not its aliases; and plugin skills never collide at all, because they load namespaced as /plugin-name:skill-name.

08Subagents in the codebase

What a subagent is and when to reach for one belongs to the agent-patterns domain; Claude Code asks you where subagents are defined. File-based ones are Markdown files in .claude/agents/ — front-matter for name, description (when the parent should delegate to it), tools and model, then the body acting as its system prompt. Definition sources stack highest-first: managed settings, the --agents flag, project .claude/agents/, personal ~/.claude/agents/, then plugins. And one gotcha: after creating the first agent file in a new agents directory, restart the session before it is picked up.

Three subagents ship built in. Explore and Plan get read-only toolsets — Write and Edit are denied — Explore for searching and surveying the codebase, Plan for research during planning. general-purpose gets every subagent-available tool and is the one that makes code changes. That read-only split is a favourite exam distinction.

09The four systems, side by side

Instructions, settings, skills, subagents — four systems, four sets of file names, and three different answers to what happens when two layers collide. Before the headless half of the domain, one table to reset the picture:

10Headless: Claude Code from a script

claude -p (long form --print) runs the same agent loop non-interactively: it takes a prompt, reads piped stdin, prints the result and exits — the shape scripts, CI jobs and pipelines want, with exit code 0 on success so shell branching works. Approve tools up front rather than interactively. --allowedTools takes permission-rule syntax — Bash(git commit *), not just Bash — and --permission-mode sets whole-session behaviour: acceptEdits lets file edits through, while auto has a classifier review each action and suits longer unattended runs. Pair --permission-prompts none with either, and anything unresolved is denied instead of hanging the job.

Output shape is the --output-format flag. text is the default — plain output. json is a structured object with the answer in result plus session_id and cost metadata; add --json-schema for schema-validated output. And stream-json is newline-delimited JSON events as they happen, typically with --verbose — system events such as api_retry carry attempt and retry_delay_ms. Every run has a session id; read it out of the json output. --resume <id> picks up that exact conversation, while --continue takes the most recent — which is how a script carries context across invocations.

Two more flags that appear in questions. --bare starts a minimal session with none of the auto-discovered extras — no hooks, skills, subagents, plugins, MCP servers, auto memory or CLAUDE.md — which is what reproducible scripted runs want; configuration then arrives explicitly via --settings, --mcp-config or --append-system-prompt. And slash commands inside a -p prompt: custom commands and user-invoked skills work when included in the prompt string, and take their values as arguments (/model sonnet, /config thinking=false). But commands that exist only in the terminal interface — /login being the standard example — are not available at all.

11The traps in this domain

• —"CLAUDE.local.md is the shared team file" — the reverse. ./CLAUDE.md is shared; the local file is personal and gitignored.
• —"AGENTS.md loads alongside CLAUDE.md" — only if you configure it; by default one suppresses the other.
• —"--settings overrides organisation policy" — it outranks user and project files, not managed settings.
• —"A managed CLAUDE.md can block dangerous commands" — prose cannot enforce; use permissions.deny in managed settings.
• —"The project skill wins because it is more specific" — the order is enterprise > personal > project, so the personal skill runs.
• —"Explore can fix the files it finds" — Explore and Plan have Write and Edit denied; code changes go to general-purpose.
• —"Every slash command works headless" — custom commands and user-invoked skills work in the -p prompt string; terminal-only ones like /login do not.