Workspace setup
Allowlists and hooks
Permission rules are enforced outside the model: Claude Code's documentation says the client weighs each tool call, so brief and prompt text steers only what the agent reaches for, never what it may do1. Rules are evaluated deny first, then ask, then allow, and the first match in that order decides; specificity does not reorder anything, so a broad deny beats a narrow allow1. A deny at one settings level cannot be overridden by an allow at another, in either direction, and managed settings sit above every other source1.
Hooks are the complementary mechanism, and official guidance separates them from the brief on exactly this point: a hook runs whether or not the model would have chosen it, while a line in a brief only asks2. The precedence between the two is where most assumptions break.
| Mechanism | What it decides | What beats it |
|---|---|---|
| deny rule | blocks the call | no allow rule, at any level, and no hook allow |
| ask rule | prompts you | a deny rule, or a blocking hook exiting 2 |
| allow rule | runs without a prompt | deny, ask, or a hook exiting 2 |
| hook returning allow | skips the prompt | a matching deny or ask rule |
| hook exiting 2 | blocks before rules are read | nothing on most blocking events, though a Stop hook used as a gate is overridden after 8 consecutive blocks |
| file pulled in with an at-sign | inserted while building the prompt | only a Read deny rule |
Three claims here are easy to blur together. A hook's allow decision does not bypass a matching permission rule: a matching deny rule still blocks the call and a matching ask rule still prompts you1. Separately, no allow rule at one settings level overrides a deny rule at another1. And a hook that exits with code 2 blocks the call before permission rules are evaluated at all, pre-empting whichever of deny, ask or allow would otherwise have applied1. The pre-tool hook itself fires only when the agent calls a tool, so a file referenced with an at-sign in your prompt, inserted while the prompt is built, needs a Read deny rule to fence it3.
The boundary is what a rule is matched against. A Bash rule is compared against the text of the command rather than the program it ends up running, and the documentation says such a rule "isn't a security boundary around the program"1: a deny on one spelling of a command does not stop another spelling, and wrappers outside Claude Code's built-in stripping list are not unwrapped. A command hook is not fenced either: it executes with whatever access your own account carries3. The documentation points at operating-system sandboxing for real enforcement, which this page does not cover.
参考文献
测验
A hook returns an allow decision for a call that a deny rule also matches. What happens?
- The call is blocked
- The call runs, because the hook decided closer to the tool
- You are prompted to confirm the call
A hook's allow decision does not bypass permission rules, so a matching deny still blocks the call. A hook exiting 2 stops a call before rules are read, but only on a blocking event.
A file referenced with an at-sign in a prompt is inserted while the prompt is being built. Fencing that exact path requires a ____.
- Read deny rule
- Bash deny rule
- Read ask rule
PreToolUse hooks fire only when a tool is called, and an at-sign reference is inserted before any tool call, so only a Read deny rule, matched against the path, blocks it.
A deny rule written for one spelling of a Bash command also stops the other ways of invoking the same program.
- True
- False
Bash rules are matched against the command text rather than the program, so an alternate spelling or a wrapper outside the built-in stripping list can slip through. Real enforcement needs operating-system sandboxing.
评论
还没有评论，来说第一句吧。