Designing allow, deny and hooks is becoming the new code review A developer argues that on teams using coding agents daily, the highest-leverage review shifts from reading code diffs to designing allow, deny and hook rules, citing Claude Code documentation that settings rules are enforced by the client regardless of what the model decides, while CLAUDE.md instructions are context only and not a hard enforcement layer. The essay maps review checklist items a machine can decide — such as touching production config or leaking credentials — onto permissions.deny, permissions.ask and PreToolUse hooks, noting that deny rules block before the classifier is consulted and cannot be overridden by user intent. The author stresses that permissions never review correctness, so this is a layer added in front of code review rather than a replacement. Originally published at https://aicoding-guide.com https://aicoding-guide.com/en/posts/essay-permissions-are-code-review/ . On a team that uses coding agents daily, the highest-leverage thing to review shifts from the code itself to the design of allow, deny and hooks. Reading diffs afterwards does not go away. But a layer appears in front of it, and that layer stops more incidents than the reading does. The argument rests on a line the tools' own documentation draws, not on a hunch. Key point The claim - The docs separate instruction from enforcement, and CLAUDE.md sits on the instruction side - Permission rules and hooks are the executable form of the review checklist items a machine can decide - But permissions never review correctness — this is a layer added in front of review, not a replacement The Claude Code memory page settles the question about organization-wide CLAUDE.md in one sentence: Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer. The same page names where to go when you need certainty: Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead. A document holding your project's rules is something that gets read, and followed on a best-effort basis . Its content arrives as a user message after the system prompt, not as part of it. No amount of work sharpening its prose changes which side of the line it sits on. That line maps directly onto review. Writing "please don't force push" in a review comment and writing it into permissions.deny differ in strength. The first may need writing again next week; the second is finished when you write it. A review checklist mixes two kinds of item: the ones a person must read to judge — design intent, naming, whether the abstraction holds — and the ones a machine can decide, such as "did this touch production config" or "did a credential reach the logs." The second kind can be written as a rule. And when you do, the docs guarantee different strengths. | Where it lives | What the docs say | Strength | |---|---|---| | permissions.deny | "Blocks before the classifier is consulted. Neither the classifier nor user intent can override it" | Before the classifier; intent cannot reach it | | permissions.ask | "Always prompts for a command that matches a content-scoped rule like the recipe above. The classifier cannot auto-approve a matching action" | Always reaches a human | | Critical-path removals | "Recognized rm and rmdir critical-path removals, which no allow rule or PreToolUse hook \"allow\" approves" | Neither a rule nor a hook can approve it | | PreToolUse hook | "To block an action regardless of what Claude decides" | Runs without going through Claude's judgement | | CLAUDE.md | "not a hard enforcement layer" | Instruction | The top four rows are checklist items you can express as configuration instead of comments. For anything in deny , the probability of missing it in review is not reduced — it leaves the realm of probability. For the mechanics, see Claude Code permissions in settings.json and settings.local.json https://aicoding-guide.com/en/posts/claude-code-settings-json-permissions/ and Claude Code permissions by example https://aicoding-guide.com/en/posts/claude-code-permissions-examples/ . For the hook side and where it stops being reliable, see Block rm -rf with a Claude Code PreToolUse hook, and know its limits https://aicoding-guide.com/en/posts/claude-code-hooks-block-rm/ . "Designing permissions" covers three distinct things. permissions ; in Codex it is named profiles, permissions.