CLAUDE.md
The instruction file you write for Claude Code: conventions, build commands, your team's rules. Four scopes exist, and every discovered file is added to context rather than replacing what came before.
Exam context: Content, not configuration. It shapes behaviour and enforces nothing, which is why a prohibition that must be enforced belongs in a deny rule instead.
See also: 3.1 Claude Code Operation
CLAUDE.md Hierarchy
The four scopes, broadest first: managed policy, user ~/.claude/CLAUDE.md, project ./CLAUDE.md or ./.claude/CLAUDE.md, and local ./CLAUDE.local.md. Claude Code searches upward through the directory tree from the working directory and loads every level it finds.
Exam context: Discovered files concatenate, ordered broadest to most specific, so a nearer file is simply read last. Reading the hierarchy as a precedence chain is the typical error in this domain; settings are the configuration source with the real chain. To stop a file loading at all, claudeMdExcludes skips CLAUDE.md and rules files by path or glob from any settings file (September 2026), managed policy files excepted. From v2.1.277 an AGENTS.md loads by default only when no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md exists in the working directory or above; Project instructions set to claude-md-and-agents-md in /config loads both.
See also: 3.1 Claude Code Operation
CLAUDE.local.md
Personal project instructions, kept out of version control. It sits at the most specific end of the memory hierarchy and is read after the CLAUDE.md in the same directory.
Exam context: The pair to .claude/settings.local.json, and easy to confuse with it under time pressure. This one carries prose for one person on one machine; the other carries configuration. It also counts as a CLAUDE.md file, so adding one to a repository that relies on AGENTS.md switches AGENTS.md off unless Project instructions is set to claude-md-and-agents-md.
See also: 3.1 Claude Code Operation
Managed Policy File
The organisation-wide CLAUDE.md deployed by IT: /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. Individual settings cannot exclude it.
Exam context: The broadest memory scope, and the parallel to managed settings at the top of the settings chain. Both are the answer when something must reach every engineer regardless of local configuration. This file is still context, and the settings file still enforces.
See also: 3.1 Claude Code Operation
@path Import
The syntax that pulls another file's content into a CLAUDE.md from anywhere in it. Relative paths resolve against the file containing the import, imports expand at launch, and recursion is capped at a maximum depth of four hops, or four levels of nested imports.
Exam context: The four-hop limit and the file that relative paths resolve against are both tested. Imports extend a file you already load; they play no part in discovering CLAUDE.md files in parent directories, which the upward search finds on its own.
See also: 3.1 Claude Code Operation
Repository Initialization (/init)
The built-in command that analyses a codebase and generates a starting CLAUDE.md of build commands, test instructions and conventions.
Exam context: Where a CLAUDE.md already exists it suggests improvements rather than overwriting. Wrong options have it silently replacing the file, or generating settings.json, which it does not touch.
See also: 3.1 Claude Code Operation
/context
The built-in command that reports what is consuming the context window, listing loaded instruction files under Memory files.
Exam context: It reports and frees nothing. When a question asks how to confirm which files a session actually loaded, this is the mechanism; when it asks how to free space, the answer is /compact.
See also: 3.1 Claude Code Operation
Auto Memory (Agent Memory)
The notes Claude keeps for itself at ~/.claude/projects/<project>/memory/. A MEMORY.md index loads at the start of every conversation, capped at its first 200 lines or 25KB, with topic files read on demand. On by default, per repository, shared across worktrees, machine-local.
Exam context: CLAUDE.md is what you write for Claude; auto memory is what Claude writes for itself. Machine-local is the tested property: a clean clone starts with none of it. autoMemoryEnabled: false in a project's settings switches it off for that repository; the /memory toggle, which writes your user settings, and CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 switch it off across all your projects.
See also: 3.1 Claude Code Operation
Rules
Standing constraints as markdown files under .claude/rules/ (project) and ~/.claude/rules/ (user). A project rule with no paths field loads at launch with the same priority as .claude/CLAUDE.md, and paths frontmatter scopes a rule to matching files instead. User rules load before project rules, but neither set overrides the other: where they conflict, Claude may follow either.
Exam context: The guide's Rules component covers two mechanisms that are not equally binding: these instruction files, which are context, and the permissions rules in settings.json, which the client enforces.
See also: 3.1 Claude Code Operation
Skill
A packaged procedure: a directory that holds a SKILL.md with YAML frontmatter and markdown instructions. Personal skills are in ~/.claude/skills/<name>/, and project skills are in .claude/skills/<name>/. Managed settings and plugins can supply skills too. Claude invokes one when its description matches the task, or you type /skill-name.
Exam context: The body loads only when used, so a long procedure uses no context until it is invoked. Name collisions across scopes resolve enterprise over personal over project, the inverse of settings precedence, which is exactly what the wrong options rely on. skillOverrides in settings (September 2026) changes a skill's visibility without editing it: user-invocable-only hides it from Claude but keeps /name, name-only drops its description, off hides it everywhere.
See also: 3.1 Claude Code Operation
Custom Command
A project- or user-defined slash command. A file at .claude/commands/<name>.md creates /name, and custom commands have merged into skills: a skill at .claude/skills/<name>/SKILL.md creates the same /name with more capability.
Exam context: Existing command files keep working, and the skill takes priority in a name clash. Arguments arrive through $ARGUMENTS, with $0 and $1 indexing individual positions.
See also: 3.1 Claude Code Operation
Subagent Definition
A markdown file in .claude/agents/ (project) or ~/.claude/agents/ (user) with name and description required in frontmatter and tools, model and memory optional. The body is the subagent's system prompt.
Exam context: Each runs in its own context window and only its final result returns to the main conversation, which is why the definition has to be self-contained. Name clashes run the same way as settings precedence (September 2026): managed, then --agents JSON, then .claude/agents/, then ~/.claude/agents/, then plugins. A definition's model outranks CLAUDE_CODE_SUBAGENT_MODEL unless CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 is also set. Its permissionMode is ignored while the main session is in acceptEdits, auto or bypassPermissions, so a subagent that must never edit needs its editing tools left out of tools.
See also: 3.1 Claude Code Operation
settings.json
Claude Code's configuration file: permissions, hook configuration, env, model selection and operational toggles. .claude/settings.json is the checked-in team baseline.
Exam context: Configuration, not prose. If a question describes instructions or conventions, the answer is CLAUDE.md. If it describes what Claude may and may not do, the answer is this file. It also carries outputStyle, statusLine, sandbox, and extraKnownMarketplaces with enabledPlugins for sharing plugins. A cloned repository cannot give itself permissions (September 2026). Its permissions.allow rules, additionalDirectories and .mcp.json approvals such as enabledMcpjsonServers take effect only once someone accepts the workspace trust dialog. Deny and ask rules apply regardless.
See also: 3.1 Claude Code Operation
settings.local.json
Personal per-project configuration at .claude/settings.local.json, auto-gitignored: Claude Code adds **/.claude/settings.local.json to your global git excludes file.
Exam context: It outranks the checked-in project file, which is its purpose. Gitignored means excluded from version control, not from loading, and the wrong option that says otherwise appears in every second settings question.
See also: 3.1 Claude Code Operation
Settings Precedence
The chain, highest to lowest: managed settings, command line arguments, .claude/settings.local.json, .claude/settings.json, ~/.claude/settings.json.
Exam context: Local takes priority over project, and project over user, for a single value such as model. Being checked in gives a file no priority, and user settings sit at the bottom rather than the top however personal the preference feels. List settings such as permissions.allow merge across files instead (September 2026), so a local file can add a rule but never remove a shared one. To restore the approval prompt for a command the team allows, add an ask rule, because rules are checked deny, then ask, then allow.
See also: 3.1 Claude Code Operation
permissions.deny Rule
A settings entry naming a tool and pattern that Claude Code refuses to run, such as Bash(git push *) or Read(./.env).
Exam context: Enforced by the client whatever the model decides, and binding in every permission mode including bypassPermissions. When a question says a file or command must never be touched, this is the right answer and a CLAUDE.md sentence is the wrong option.
See also: 3.1 Claude Code Operation
Permission Mode
The setting that controls how much Claude Code does without asking: default (labelled Manual, alias manual), acceptEdits, plan, auto, dontAsk and bypassPermissions. Shift+Tab cycles modes mid-session; permissions.defaultMode sets the starting point. In .claude/settings.json or .claude/settings.local.json (September 2026), an auto value does not take effect and the built-in default applies. Nor does bypassPermissions, which starts the session in Manual. From v2.1.283 the built-in default for interactive terminal and VS Code sessions is auto on every plan and provider; claude -p starts in Manual.
Exam context: The guide's auto-mode feature, and the config values are exact. Choose by isolation and reversibility, not by how much waiting the engineer will tolerate.
See also: 3.1 Claude Code Operation
acceptEdits
The mode that auto-approves file edits and the common filesystem commands mkdir, touch, rm, rmdir, mv, cp and sed inside the working directory (September 2026).
Exam context: The right answer for iterating on code you will read in a diff afterwards. It approves edits, not arbitrary shell commands, which is the difference the wrong options make unclear.
See also: 3.1 Claude Code Operation
plan
The mode in which Claude reads and explores while edits stay blocked until you approve the plan. Approving switches the session into an editing mode.
Exam context: The right answer for unfamiliar code and for a question that wants a proposal before any change is made. It blocks edits across the whole repository, so it is the wrong tool for protecting one specific path.
See also: 3.1 Claude Code Operation
dontAsk
The mode that auto-denies anything that would have prompted, running only pre-approved tools and the read-only command set.
Exam context: The CI answer: a session that must never wait for input and must never quietly give itself more permissions. It needs an explicit allow list to get anything done, which is what makes it auditable. Where an unattended run's commands cannot be listed in advance, --permission-mode auto has the classifier vet each one instead.
See also: 3.1 Claude Code Operation
bypassPermissions
The mode that runs everything without checks, documented for isolated containers and VMs only. --dangerously-skip-permissions is its flag form.
Exam context: Two rules survive it: deny rules still block, and allow rules stop mattering entirely. A resume never brings it back, and a bypassPermissions value in .claude/settings.json or .claude/settings.local.json does not take effect (September 2026). Set it at launch, or in user, --settings or managed settings.
See also: 3.1 Claude Code Operation
Session Transcript
The JSONL file at ~/.claude/projects/<project>/<session-id>.jsonl that Claude Code writes continuously as a conversation runs.
Exam context: Sessions persist whatever you do, so "the conversation is gone" is never the right answer. To return to a session, use claude --continue for the most recent session in the directory, claude --resume for the picker or a named ID, and /resume from inside a session. As of September 2026, only a terminal resume by --continue, ID or unique name restores the permission mode. It does not restore bypassPermissions or plan, which are among a few narrower cases. The picker and /resume do not restore the stored mode. A claude -p resume starts in the same mode as a new -p run. Launch flags such as --add-dir and --mcp-config must be passed again. /branch, or --fork-session on a resume, copies the conversation into a new session and leaves the original intact.
See also: 3.1 Claude Code Operation
/clear
The in-session command that starts a conversation with empty context, for work unrelated to what came before.
Exam context: The old conversation stays on disk and reopens through /resume. Using it in the middle of a task to free space is the anti-pattern that exam scenarios describe, because the session then knows nothing about the task it is still working on.
See also: 3.1 Claude Code Operation
/compact
The in-session command that replaces the conversation history with a summary, optionally focused by instructions you pass it.
Exam context: The right command when the same task continues and the context window is filling. Compaction keeps a summary of the conversation, and clearing starts with an empty context. Wrong options offer /context as a third choice, but reporting usage frees nothing.
See also: 3.1 Claude Code Operation
Headless Mode (claude -p)
Non-interactive Claude Code: you give it a prompt and it returns a result, with no human at the terminal. Piped stdin is capped at 10MB, and the exit code is 0 on success so scripts can branch.
Exam context: A -p run starts in Manual on every plan, so scripted work sets which actions it may take without asking, with --permission-mode and --allowedTools. Its sessions stay out of the interactive picker and a plain claude --continue but still resume by ID, and claude -p --continue includes them. The claim that Claude Code needs a terminal is a wrong option, not a fact. It never shows the workspace trust dialog (September 2026). So in a folder nobody has trusted, it ignores project permissions.allow rules. It still runs settings-file hooks and connects .mcp.json servers, unless --bare or --setting-sources user stops them.
See also: 3.1 Claude Code Operation
stream-json
The output format that emits newline-delimited JSON events as a run progresses. The stream includes a system/init event with session metadata and ends with a result message.
Exam context: Token deltas (each new piece of output as it is generated) need this format plus --verbose and --include-partial-messages. The other formats are text, the default, and json, the single payload carrying result, session_id, cost and usage. Invented flags such as --stream are a common wrong option. Subagent messages carry parent_tool_use_id, with null for the main conversation; --forward-subagent-text adds each subagent's text and thinking to its tool calls (September 2026).
See also: 3.1 Claude Code Operation
--bare
The flag that skips auto-discovery of hooks, skills, custom commands, subagents, installed plugins, MCP servers, auto memory and CLAUDE.md, so a bare run gets what it needs by flag, such as --agents or --mcp-config.
Exam context: Dated current state, September 2026: the docs recommend it for scripted and SDK calls and expect it to become the default for -p. The reason to use in a question is reproducibility, since nothing in a developer's home directory can then change what a pipeline runs.
See also: 3.1 Claude Code Operation