Practice — Settings, Permissions & Hooks (17 questions)

Your team's .claude/settings.json contains:

{
  "permissions": {
    "allow": ["Bash(aws s3 ls)"],
    "deny": ["Bash(aws *)"]
  }
}

An engineer reports that aws s3 ls still prompts for approval every time, even though they explicitly allowed it.

1. Explain exactly why the allow rule has no effect here.
2. Rewrite the configuration so that aws s3 ls runs without a prompt while every other aws subcommand still requires approval.
3. A teammate suggests moving the allow rule into .claude/settings.local.json instead, reasoning that local settings have higher precedence than project settings. Would that fix it? Why or why not?

Your team keeps a machine-generated .env.production file that Claude should never be allowed to modify, no matter what a prompt or a compromised instruction asks for. You want to register a hook that, when it exits with status 2, guarantees the edit never lands on disk in the first place — not one that merely notices the change after the fact.

Which hook event should this guardrail be registered on?

Your npm test output floods the context with thousands of lines of passing-test noise on every run.

What mechanism lets you filter that output down to just the failures before it ever reaches Claude's context?

You want a verification check to do more than run once — you want it to actually gate whether Claude Code is allowed to consider the task done, scaling up as a run becomes less attended.

Put these in the order of escalating rigor this subject describes: a Stop hook, a one-off prompt instruction, a verification subagent, a /goal condition.

You've set up a Stop hook that blocks the turn from ending until your check passes, intending it as a hard gate on an unattended run.

After how many consecutive blocks does Claude Code override it and let the turn end anyway?

A task needs to edit both packages/api/ and a shared types package outside your current scope. You could add additionalDirectories to settings, or pass --add-dir at launch.

What's the concrete difference between them?

You write Bash(git diff*) in permissions.allow, intending it to match git diff and its variants. A teammate points out it also silently matches git diff-index.

What's the actual fix?