CCDV-F Glossary - Claude Code

Quick-lookup definitions for every domain, with exam context and links back to the lesson that covers each term.

CLAUDE.md: A file placed in a project root that gives Claude Code persistent context about that codebase - conventions, commands to run, things to avoid - read automatically at the start of every session so you don't need to re-explain them each time. Because Claude follows it confidently even when it's stale, the discipline is keeping it accurate: update it in the same commit that changes the convention it documents.; Exam context: The exam tests that CLAUDE.md is prompt-level (probabilistic) guidance, not a hard enforcement mechanism - a strongly worded instruction in it ("always run the linter before committing") is not guaranteed to be followed every time; that guarantee requires a permission deny rule or a PreToolUse hook instead.; See also: 7.1 - Operating Claude Code Day to Day
CLAUDE.md Hierarchy: CLAUDE.md resolves across three scopes, broadest to narrowest: an enterprise managed policy file deployed by an organization's IT/security team (outside any repo, not overridable by project or user files); a project-level CLAUDE.md at the repo root (checked into version control, shared team-wide - build commands, architectural conventions, style rules); and a user-level ~/.claude/CLAUDE.md that applies across all of that individual's projects and holds personal preferences only. Root files can also use @path/to/file imports to pull in more detailed docs (e.g. a testing guide) without bloating the file loaded on every session.; Exam context: A classic distractor has a developer write personal formatting preferences directly into the committed project-level file. The correct answer is that personal preferences belong in the user-level ~/.claude/CLAUDE.md instead, since the project file is shared and teammates never see the user-level one.; See also: 7.1 - Operating Claude Code Day to Day
Permission System (allow / ask / deny): The mechanism, configured in settings.json (not CLAUDE.md prose), that gates which tools Claude Code may use. Rules are written as Tool(pattern) strings - e.g. Bash(git commit:*), Bash(rm:*), Edit - and each is placed in one of three lists: allow (runs without prompting), ask (prompts the user first), or deny (blocked outright, no prompt). Settings live at multiple scopes: checked-in .claude/settings.json (team), gitignored .claude/settings.local.json (individual overrides), user-level ~/.claude/settings.json, and an enterprise-managed file, with higher scopes generally taking precedence and enterprise policy always winning.; Exam context: Expect scope-precedence questions layered with the deny-vs-allow question - don't conflate "which scope wins" with "which rule type wins when both match"; those are two separate exam-tested rules (see "Deny-Overrides-Allow Rule").; See also: 7.1 - Operating Claude Code Day to Day
Deny-Overrides-Allow Rule: Within permission evaluation, a matching deny rule always wins over a matching allow rule, regardless of which settings.json file (project, local, user, enterprise) each rule came from. An allow rule at any scope cannot override a deny rule that also matches the same command.; Exam context: The signature exam trap: a command matches an allow rule in one settings file and a deny rule in another, and the distractor answers pick "whichever file is narrower/closer in scope" or "whichever rule was added most recently." The correct rule is scope-independent - deny beats allow whenever both match, full stop.; See also: 7.1 - Operating Claude Code Day to Day
Hooks: A deterministic control mechanism, configured in settings.json and distinct from probabilistic CLAUDE.md prose, that binds a shell command to a lifecycle event: PreToolUse (fires before a tool runs, can block it), PostToolUse (fires after, can react to the result), UserPromptSubmit (fires when the user submits a prompt), and Stop (fires when Claude finishes responding) - optionally filtered to specific tools via a matcher pattern. The hook script receives event details as JSON on stdin; exit code 0 lets execution continue normally, while exit code 2 blocks the action and feeds the script's stderr back to Claude as the reason.; Exam context: Exam scenarios ask which mechanism guarantees a rule holds every single time (e.g. "always block force pushes"); the answer is a PreToolUse hook (or a deny rule) - not a CLAUDE.md instruction, which is only usually followed. Also know that exit code 2 specifically is what blocks and surfaces a reason to Claude, not just any non-zero code.; See also: 7.1 - Operating Claude Code Day to Day
Custom Slash Commands: A repeated prompt or workflow packaged as a short, memorable invocation: a Markdown file under .claude/commands/ (project-scoped, shared) or ~/.claude/commands/ (personal) becomes a command named after the file, its body is the prompt template, and $ARGUMENTS in that body is substituted with whatever text follows the command name when invoked. Frontmatter can restrict allowed tools and add a description for /help; subdirectories namespace commands (.claude/commands/git/commit.md becomes /git:commit).; Exam context: Distinguish these from the built-ins /clear (wipes context, starts fresh - for switching to an unrelated task) and /compact (summarizes and shrinks the current conversation instead of discarding it - for staying on the same task as it approaches the context window). A scenario about switching to an unrelated task expects /clear, not a new slash command or /compact.; See also: 7.1 - Operating Claude Code Day to Day
Headless Mode (-p / --print): Claude Code's non-interactive mode that runs a single prompt to completion without a human at the keyboard - the shape a CI pipeline needs, e.g. an automated PR review step. Invoked with claude -p "<prompt>" (or --print); instead of dropping into the interactive REPL, Claude Code executes the task and exits, returning a non-zero exit code on failure so a pipeline step can branch on it.; Exam context: The exam frames this as the CI-appropriate mode versus interactive mode with a human watching - a distractor pairs "interactive mode with a human present" with CI, which defeats the point of automation.; See also: 7.2 - Running Claude Code in CI/CD
--output-format (text / json / stream-json): The flag controlling what headless mode returns. text (default) prints the final response as plain text - fine for a human reading a log, fragile for a script. json returns a single JSON object once the run completes, including the final result, session ID, and usage/cost data - what a CI script should parse to decide pass/fail. stream-json emits newline-delimited JSON events as the run progresses (tool calls, intermediate results, final message) rather than waiting for completion, useful for streaming progress into a log during a long CI step.; Exam context: A signature distractor is parsing free-text (default) output with regex/keyword matching in a CI script - fragile, since wording isn't a stable contract. The exam wants --output-format json as the reliable, machine-actionable choice.; See also: 7.2 - Running Claude Code in CI/CD
--allowedTools / --disallowedTools: CLI flags that pass an explicit tool allowlist or denylist for a single headless invocation, scoping exactly what that run can touch (e.g. allow Read and Grep, disallow arbitrary shell) - set in advance because no human is present in CI to approve a surprise permission prompt.; Exam context: Expect a scenario testing why tool scoping must be decided before the run starts rather than negotiated during it - the answer is always "no human present to approve an interactive prompt in CI."; See also: 7.2 - Running Claude Code in CI/CD
--permission-mode (plan / acceptEdits / bypassPermissions): A CLI flag selecting a broader permission policy for a headless run: plan has Claude produce a plan without executing anything; acceptEdits auto-approves file edits but still gates other risky actions; bypassPermissions (equivalent to --dangerously-skip-permissions) skips permission checks entirely, removing the safety net a human approval or a deny rule would normally provide.; Exam context: The sharpest trap in this lesson: bypassPermissions/--dangerously-skip-permissions is not "a convenience for CI" - it's acceptable only inside an ephemeral, sandboxed CI container with no access to real credentials or production systems, never on a shared/long-lived runner or a developer machine.; See also: 7.2 - Running Claude Code in CI/CD
Session Isolation in CI: The practice of starting each CI run from a clean, isolated session rather than carrying accumulated context from a previous pipeline run, so results stay reproducible and one run's review isn't contaminated by an earlier, unrelated one. A plain claude -p invocation already starts fresh; CI pipelines should deliberately avoid the --resume and --continue flags, which resume a prior session's context - exactly what a reproducible pipeline run does not want.; Exam context: This is the CI-specific instance of the same fresh-session principle as /clear in Lesson 7.1 - expect "successive CI jobs sharing a persistent session" as the wrong-practice distractor, with the fix being a fresh session (no --resume/--continue) per run.; See also: 7.2 - Running Claude Code in CI/CD
ANTHROPIC_API_KEY Authentication: The authentication path headless CI uses instead of interactive claude login (which opens a browser for OAuth and requires a human - unavailable on a CI runner). The key is populated from the CI provider's secret store as the ANTHROPIC_API_KEY environment variable, never committed to the repo or hardcoded into a workflow file.; Exam context: A straightforward distractor relies on claude login for CI auth; the exam expects you to know CI has no browser or human to complete OAuth, so an API key sourced from the platform's secret store is the only correct path.; See also: 7.2 - Running Claude Code in CI/CD
--max-turns: A flag that bounds how many agentic turns a single headless run can take before being forced to stop, which matters in CI for both wall-clock time and cost - without a cap, an unattended run could in principle keep working (and spending) far longer than intended, with no human present to notice and stop it.; Exam context: Ties to the same "no human present" theme as --allowedTools and the bypassPermissions caution - expect this framed as a cost/safety bound specific to unattended runs, distinct from tool scoping (which limits what a run can touch, not how long it can run).; See also: 7.2 - Running Claude Code in CI/CD