The Five Components, and Where Each Lives (3.1)
The guide names Rules, Skills, Commands, Agents and Agent Memory. Each one is a file you can open, and nearly every item in this domain is a placement question: given a stated need, which family and which scope.
| Component | What it is | Where it lives |
|---|---|---|
| Rules | Markdown constraints; a project rule loads at launch with the same priority as .claude/CLAUDE.md, and paths frontmatter scopes a rule to matching files. User rules load first, but neither set overrides the other, so Claude may follow either where they conflict | .claude/rules/, ~/.claude/rules/, plus the permissions block in settings.json |
| Skills | A directory holding a SKILL.md; the body loads only when used, invoked by description match or as /skill-name. skillOverrides in settings changes its visibility without editing it | .claude/skills/<name>/, ~/.claude/skills/<name>/, managed settings, plugins |
| Commands | Built-in slash commands running fixed CLI logic, bundled prompt-based skills such as /doctor, and custom commands, which have merged into skills | The CLI itself; .claude/commands/<name>.md |
| Agents | Subagents with name and description required in frontmatter; each runs in its own context window and only its final result returns | .claude/agents/, ~/.claude/agents/ |
| Agent Memory | Auto memory, the notes Claude keeps for itself; the MEMORY.md index loads at the start of every conversation, capped at its first 200 lines or 25KB. autoMemoryEnabled: false in project settings turns it off for one repository | ~/.claude/projects/<project>/memory/ |
Collisions. A skill and a command file of the same name both create /name, and the skill wins. Across scopes, skill collisions resolve enterprise over personal over project, the exact inverse of settings precedence, and a favourite trap. Subagent names follow the settings direction instead: managed, then --agents JSON, then .claude/agents/, then ~/.claude/agents/, then plugins. Both invocable kinds take arguments through $ARGUMENTS, with $0 and $1 indexing positions zero-based, so $0 is the first argument.
Around the five (September 2026).
skillOverrides:user-invocable-onlyhides a skill from Claude but keeps/nameworking,name-onlylists it without its description,offhides it everywhere. The/skillsmenu saves the choice to.claude/settings.local.json.- Subagent model: a definition's
model, or one Claude passes at spawn time, outranksCLAUDE_CODE_SUBAGENT_MODEL. AddCLAUDE_CODE_SUBAGENT_MODEL_FORCE=1to put every subagent on that model (needs v2.1.257 or later; forks andmodel: inheritskills still use the main model). - Subagent
permissionMode: ignored while the main session is inacceptEdits,autoorbypassPermissions; the subagent takes the parent's mode. To stop a subagent editing in every mode, leave editing tools out of itstoolslist. - Plugins: skills, subagents, hooks and MCP servers packaged as one unit. A repository shares a private marketplace's plugin through
extraKnownMarketplacesandenabledPluginsin its.claude/settings.json; the marketplace entry applies once a contributor trusts the folder. Managed settings carry the same two keys fleet-wide. - Output styles:
.claude/output-styles/or~/.claude/output-styles/, chosen withoutputStyle. On the full system prompt, a custom style drops Claude Code's software engineering instructions unless its frontmatter setskeep-coding-instructions: true; the shorter system prompt never carries them.
The line that settles most placement items: CLAUDE.md is what you write for Claude, auto memory is what Claude writes for itself. Both are context. Neither enforces anything.
CLAUDE.md Concatenates (3.1)
Four scopes, broadest first:
- Managed policy:
/Library/Application Support/ClaudeCode/CLAUDE.md(macOS),/etc/claude-code/CLAUDE.md(Linux and WSL),C:\Program Files\ClaudeCode\CLAUDE.md(Windows). Deployed by IT, not excludable by individual settings. - User:
~/.claude/CLAUDE.md, following you into every project. - Project:
./CLAUDE.mdor./.claude/CLAUDE.md, shared through version control. - Local:
./CLAUDE.local.md, personal and gitignored.
Discovered files are concatenated into context, never overridden: a more specific file lands after a broader one rather than replacing it. Claude Code walks up the directory tree from the working directory, so a session launched in foo/bar/ reads foo/CLAUDE.md before foo/bar/CLAUDE.md, each CLAUDE.local.md after its sibling. Files in subdirectories below load on demand when Claude reads there.
@path/to/importpulls in content from anywhere in a CLAUDE.md. Relative paths resolve against the file containing the import, imports expand at launch, and recursion stops at a maximum depth of four hops. A path in backticks stays literal./initis repository initialisation: Claude analyses the codebase and writes a starting CLAUDE.md of build commands, test instructions and conventions. Where one already exists it suggests improvements rather than overwriting./contextproves what actually loaded, under Memory files./memoryopens any of it for editing.claudeMdExcludes(September 2026) skips CLAUDE.md and rules files by path or glob, from any settings file; managed policy files cannot be excluded. In.claude/settings.local.jsonit keeps another team's file out of your sessions only.AGENTS.md(v2.1.277 or later) loads by default only when noCLAUDE.md,.claude/CLAUDE.mdorCLAUDE.local.mdexists in the working directory or above, so a personalCLAUDE.local.mdswitches it off. Project instructions set toclaude-md-and-agents-mdin/configloads both; Claude Code ignores that value in project and local settings files.
settings.json Overrides (3.1)
Settings run the other way, as a genuine precedence chain:
| Rank | Source | Notes |
|---|---|---|
| 1 | Managed settings | The OS policy directory; cannot be overridden |
| 2 | Command line arguments | Temporary session overrides |
| 3 | .claude/settings.local.json | Personal per-project state, auto-gitignored |
| 4 | .claude/settings.json | The team baseline, checked in |
| 5 | ~/.claude/settings.json | Applies when nothing else specifies the setting |
Local beats project beats user is the order items key on for a single value such as model, and the middle boundary is where candidates slip: being checked in confers no rank. List settings such as permissions.allow merge across files (September 2026), so a local file can add entries but never remove a shared one. To prompt for a command the team allows, add an ask rule: rules are checked deny, then ask, then allow. Claude Code auto-gitignores the local file by adding **/.claude/settings.local.json to your global git excludes file, which excludes it from version control and not from loading.
Settings carry permissions (allow, ask, deny, defaultMode, additionalDirectories), hooks wiring, env, model selection, and toggles such as autoMemoryEnabled.
Workspace trust (September 2026). A cloned repository cannot grant itself capability: the permissions.allow rules and additionalDirectories in its .claude/settings.json, and .mcp.json approvals such as enabledMcpjsonServers committed there, take effect only once someone accepts the trust dialog for that folder. Deny and ask rules apply regardless.
Status line. statusLine runs your script with session JSON on stdin and re-runs it on events such as a new assistant message, so it can go quiet while the main session sits idle; refreshInterval adds a timer. Key any cache on the input's session_id, not a process ID, which changes on every run.
The sentence items are built from, verbatim from the memory page: "Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer." When a stem says must never, the keyed answer is configuration, not prose.
Sessions, /clear and /compact (3.1)
Sessions save continuously as local JSONL transcripts at ~/.claude/projects/<project>/<session-id>.jsonl, so exiting loses nothing.
| Route | What it reaches |
|---|---|
claude --continue (-c) | The most recent session in the current directory |
claude --resume | The interactive picker |
claude --resume <name-or-id> | That specific session |
/resume | Another conversation, from inside a running session |
/branch, or --fork-session on a resume | A copy of the conversation as a new session, leaving the original intact |
Sessions created by claude -p or the Agent SDK stay out of both the picker and a plain claude --continue (September 2026). They still resume by ID, and claude -p --continue includes them. A resumed session brings back the conversation and the model it was using. The permission mode is fussier (September 2026): it comes back only on a terminal resume by --continue, by ID or by a unique name without -p, and even then not for bypassPermissions or plan (among a few narrower cases), which fall back to the mode a new session would start in. The picker and /resume never restore it. claude -p --resume or -p --continue starts where a new -p run would, bar one narrow plan-mode case. Launch flags do not survive a resume either: pass --add-dir, --mcp-config, --settings, --plugin-dir or --fallback-model again, or move the setting into a settings file, which is re-read at every launch.
Inside a session: /clear starts an empty context for unrelated work, and the old conversation stays on disk and resumable. /compact [instructions] replaces history with a summary so the same task continues. /context shows what is eating the window. Treating the two as interchangeable ways to free space is the standing trap: only one of them keeps the task alive.
Headless and Streaming (3.1)
claude -p (--print) is the non-interactive mechanism: prompt in, result out, piped stdin up to 10MB, exit 0 on success and non-zero on failure so scripts can branch. It starts in Manual on every plan, so scripted runs declare their own autonomy.
| Need | Flags |
|---|---|
| Plain text back | --output-format text (the default) |
| One machine-readable payload | --output-format json, carrying result, session_id, cost and usage |
| Events as the run progresses | --output-format stream-json, newline-delimited, carrying a system/init event of session metadata and ending with a result message |
| Token deltas | stream-json plus --verbose and --include-partial-messages |
| Schema-conforming output | --output-format json with --json-schema, read back from structured_output |
| Subagent text and thinking in the stream | --forward-subagent-text; file each message by parent_tool_use_id, where null marks the main conversation |
| Autonomy for the run | --permission-mode, --allowedTools (permission-rule syntax) |
| A scripted follow-up | --continue, or --resume <session-id> captured from the JSON payload |
Dated current-state note (September 2026): --bare skips auto-discovery of hooks, skills, custom commands, subagents, installed plugins, MCP servers, auto memory and CLAUDE.md. The docs recommend it for scripted and SDK calls and expect it to become the default for -p. A bare run gets what it needs by flag, such as --agents or --mcp-config. A -p run never shows the trust dialog. In a folder nobody has trusted, it ignores the project's permissions.allow rules with a stderr warning, yet without --bare it still runs the hooks in the project's settings files and connects its .mcp.json servers. Allow rules off, hooks and servers on. For a checkout you did not write, --bare or --setting-sources user keeps both out, and the allowlist goes on the command line with --allowedTools.
Invented near-miss flags are the standing distractor here: --headless, --stream and --auto do not exist.
The Permission-Mode Axis (3.1)
The guide's auto-mode feature. Config values are exact, and near-misses are the distractors:
| Mode | Runs without asking |
|---|---|
default (Manual in the CLI, alias manual) | Reads only |
acceptEdits | File edits and the common filesystem commands mkdir, touch, rm, rmdir, mv, cp and sed, for paths inside the working directory |
plan | Reads and exploration; edits stay blocked until you approve the plan |
auto | Whatever a second model, the classifier, approves in your place |
dontAsk | Only pre-approved tools and the read-only set; anything that would have prompted is denied |
bypassPermissions | Everything, for isolated containers and VMs only; --dangerously-skip-permissions is its flag form |
Two rules outlive every mode: deny rules block even under bypassPermissions, and allow rules have no effect there.
Shift+Tab cycles modes mid-session and permissions.defaultMode sets where sessions start, with two exceptions in .claude/settings.json and .claude/settings.local.json. An auto value there does not take effect, and Claude Code falls back to the built-in default. Nor does bypassPermissions, which starts the session in Manual. Dated current-state note (September 2026): from Claude Code v2.1.283, interactive terminal and VS Code sessions start in auto mode on every plan and provider, while claude -p starts in Manual on every plan. A managed defaultMode only sets the starting point, and people can still switch to auto. disableAutoMode set to "disable" in managed settings takes it out of reach.
The Bash sandbox (September 2026) is a separate layer: the mode decides whether Claude asks, and the sandbox has the operating system limit what a command and its child processes can reach. sandbox.filesystem.allowWrite opens one extra writable path, such as a build cache, which the docs prefer to exempting the tool through excludedCommands. sandbox.allowUnsandboxedCommands: false closes the escape hatch in which Claude retries a blocked command outside the sandbox.
The judgement items reward: raise autonomy in proportion to isolation and reversibility. acceptEdits for edits you will read in a diff, plan before touching code you do not know, dontAsk with an explicit allowlist for CI, auto for an unattended run whose commands cannot be listed in advance, bypassPermissions only where the whole environment is disposable.