3.3–3.4 settings.json and Claude Code's Operating Modes

settings.json — at ~/.claude/settings.json for the user level and .claude/settings.json at the project level — is where Claude Code's behavior and permissions are actually configured. It's the deterministic control surface: which tools are allowed or denied, hook definitions (code that runs at defined points in the agent loop), environment variables, model selection, and MCP server configuration all live here.

"Deterministic" is the word to hold onto. An allow/deny rule or a hook defined in settings.json can block a dangerous command regardless of what the model proposes that turn — it doesn't matter whether the model "decided" to run rm -rf or was tricked into proposing it by adversarial input; the rule fires the same way every time, because it's enforced structurally, outside the model's discretion. This is the same idea that shows up under a different name in Domain 7 (security and safety): a prompt-level instruction is probabilistic, a settings.json rule or hook is deterministic.

• •Tool allow/deny lists — which tools Claude Code is permitted to invoke at all.
• •Hook definitions — deterministic code callbacks at defined points in the agent loop.
• •Environment variables and model selection.
• •MCP server configuration.

Lesson 3.2 already flagged this pairing; here's the fuller version. A well-written CLAUDE.md instruction — "never run destructive commands" — is not an adequate substitute for a settings.json permission rule. The former is a probabilistic nudge: the model reads it as context and generally follows it, but adversarial input, an ordinary mistake, or a long context window drifting away from an early instruction can all cause it to be missed or overridden. The latter is a deterministic gate: the code either allows the action or it doesn't, independent of the model's reasoning that turn.

PreToolUse and PostToolUse are the two hook events that come up most, because they sit directly on the tool-call boundary -- one gates whether a call happens, the other gates what comes back. But the agent lifecycle has several more hook events, each bound to a different moment in a session, configured the same way in settings.json: a lifecycle event plus a command that runs when it fires.

Claude Code conversations persist as sessions that can be resumed later rather than being lost the moment a terminal closes. /clear resets the conversation context to keep it focused — a manual antidote for when accumulated history has stopped being relevant to the current task (context rot). Beyond session basics, Claude Code exposes three operating-mode axes, and the exam consistently tests whether you can tell them apart: headless mode, streaming mode, and auto-mode.

Headless mode runs Claude Code non-interactively — for example claude -p "..." — with no interactive TUI, suited to scripting, CI pipelines, and automation. Streaming mode emits output incrementally, including structured stream-JSON, for programmatic consumption of output as it's produced rather than waiting for a final block. Auto-mode is reduced-friction autonomous operation: Claude proceeds with less step-by-step confirmation, trading human checkpoints for speed.

"claude -p" is shorthand for a small, specific flag set worth knowing individually. --print / -p is the flag that makes headless mode headless -- non-interactive output, no TUI, process the prompt and exit. --output-format is a separate, composable choice layered on top of that: a headless run can emit plain text, or it can emit structured output (e.g., stream-JSON) that a calling script parses incrementally instead of waiting for one final blob. --resume and --continue solve session continuity across separate invocations -- --resume reattaches to a specific named prior session, while --continue picks up the most recent session without naming one.

The single most repeated confusion in this task statement is headless mode vs. auto-mode, and the exam leans on it hard. Headless mode is about interactivity — is there a TUI prompting for confirmation, or not? Auto-mode is about autonomy — how many step-by-step confirmations does Claude ask for before acting, regardless of whether the session is interactive at all? A scenario describing "running in a CI pipeline" is describing headless mode; a scenario describing "letting Claude proceed without confirming each step" is describing auto-mode. They are independent settings — headless does not imply auto-mode, and a fully interactive session can still run in auto-mode.

Because auto-mode removes confirmation checkpoints, it raises the stakes of any single action Claude takes — there's no human in the loop to catch a bad call before it fires. That's exactly why auto-mode should always be paired with settings.json permission rules and hooks (from 3.3), not used unguarded: the deterministic controls that would otherwise be backed up by a confirmation prompt need to be enforced structurally instead, since the prompt-level checkpoint has been removed.

Anthropic's operational guidance for using Claude Code well is a repeatable loop: gather context, make a plan, act, and verify. Understand the task and codebase first; form an explicit plan rather than improvising step by step; execute that plan; and use tests or builds as ground-truth verification rather than trusting the model's own claim that it succeeded. Verification against an objective signal — a passing test, a clean build — is what actually closes the loop; a self-report ("I've completed the task") is not evidence on its own.

• 1.GATHER CONTEXT — understand the task and the relevant parts of the codebase before proposing anything.
• 2.MAKE A PLAN — form an explicit plan rather than improvising turn by turn.
• 3.ACT — execute the plan.
• 4.VERIFY — check against ground truth (tests, builds) rather than the model's own claim of success.

The loop is meant to be tightened over time, not re-invented every session: encode a repeated procedure once as a custom slash command (3.1) rather than re-typing a long, brittle prompt, and back a hard rule with a hook (3.3) rather than hoping a prompt instruction holds. Put together, this whole domain is really one connected system — components (3.1) that package behavior, memory (3.2) that carries context, configuration (3.3) that enforces boundaries deterministically, and modes (3.4) that determine how a session runs — all in service of the same gather → plan → act → verify discipline.