Claude Code Configuration Facts Most Guides Get Wrong

Summary:

1. Four config myths show up as wrong answers because most guides repeat them.
2. Claude Code has 30+ tools, four scopes (no plugin), the Agent tool, and hooks in settings.json.
3. Permission precedence is deny over ask over allow, and a deny cannot be overridden.
4. You get a myth-vs-fact table plus the exact config that proves each fact.

Most Claude Code configuration guides get four facts wrong, and each one is an almost-right statement that reads as reasonable until you check it. The certification exam plants those exact four as distractors, so knowing the real config surface (down to the field names) is what separates a pass from a near miss. Here they are, corrected, with the configuration to prove each one.

The four facts, corrected

These four are Domain 2, Claude Code Configuration and Workflows, which is 20% of the exam. Every one is a fact stated slightly wrong, which is the hardest kind of distractor to catch.

How does scope precedence actually work?

When the same setting appears in more than one scope, Claude Code applies them in priority order, highest to lowest:

Source: Claude Code settings docs. One caveat the docs state plainly: “Permission rules behave differently because they merge across scopes rather than override.” That asymmetry (settings override, permission rules merge) is exactly the kind of seam the exam tests.

Why did my deny rule not stop the command?

It did, if you wrote it correctly. Permission precedence is deny over ask over allow, first match wins, and a deny cannot be overridden by a broader allow:

{
  "permissions": {
    "allow": ["Bash(*)"],
    "deny":  ["Bash(rm -rf *)"]
  }
}

Run rm -rf build/ against that and it’s blocked. The broad Bash(*) allow does not win, because deny is decisive on the first match. Anyone who tells you “the broad allow wins” has the precedence inverted. The same rule closes a common gap: allow rules cannot pre-approve a protected path like .claude, because the safety check runs before allow evaluation, so those writes still prompt no matter what you allow-list.

Where do hooks actually live?

Inside settings.json, as keys. Not in a .claude/hooks/ directory of JSON files. This is the shape:

{ "hooks": { "PreToolUse": [ { "matcher": "Bash",
  "hooks": [ { "type": "command", "command": "your-check.sh" } ] } ] } }

The blocking contract is precise: a PreToolUse hook that exits with code 2 blocks the call and feeds its stderr back to Claude. Exit 0 succeeds; any other non-zero code is a non-blocking soft error. PreToolUse can block or modify a call’s input; PostToolUse runs after the tool, so it can rewrite output but cannot block what already ran.

The Task-to-Agent rename, and required frontmatter

The delegate tool is Agent, not Task. If a guide says “use the Task tool to spawn a subagent,” it’s stale: the tool was renamed, and Task* now refers to the task list. A subagent definition needs only two required frontmatter fields, name and description; everything else is optional:

---
name: reviewer
description: Reviews diffs for correctness; never edits.
tools: [Read, Grep, Glob]
model: haiku
---
You review code. You never modify files.

Note the tools list, not the prompt, is what actually enforces read-only. Omit Edit and Write and the restriction is real, not advisory.

Keep this cheat sheet where you can see it:

CLAUDE CODE CONFIG CHEAT SHEET
Tools:        30+ built-in (not 6)
Scopes:       Managed, Project, User, Local (no plugin scope)
Settings:     Managed > CLI > Local > Project > User (override)
Permissions:  deny > ask > allow, first match wins, deny can't be overridden (merge, not override)
Delegate:     the Agent tool (renamed from Task)
Hooks:        keys in settings.json; PreToolUse exit 2 blocks
Enforcement:  CLAUDE.md is context; a hook or deny rule is the enforcement layer

What should you actually do?

• If a source says “six tools” or “plugin scope” → distrust the rest of it; both are wrong, and they travel together.
• If a rule must hold every time → put it in a PreToolUse hook or a deny rule, not in CLAUDE.md. Markdown is context, not enforcement.
• If your deny rule seems ignored → check the syntax, not the precedence; deny always beats allow on the first match.
• If a guide says “the Task tool” → mentally swap in Agent and re-read the claim; if it still makes sense, it’s fine.

The bottom line

• Almost-right is still wrong. The config myths that write exam distractors are the same ones cluttering blog posts.
• CLAUDE.md is context; hooks and deny rules are enforcement. When a rule must hold, it goes in code, not markdown.
• Learn the surface precisely: 30+ tools, four scopes, deny-over-allow, hooks in settings.json, the Agent tool. Precision is the whole domain.