{
  "id": 19692957,
  "title": "Designing allow, deny and hooks is becoming the new code review",
  "url": "https://urgent.news/2026/11/12/designing-allow-deny-and-hooks-is-becoming-the-new-code-review",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-12T19:17:08.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/aicoding-guide/designing-allow-deny-and-hooks-is-becoming-the-new-code-review-3epg"
  },
  "original_language": "en",
  "account": "In a team that utilizes coding agents regularly, the focus of reviews has shifted from the code itself to the design of allow, deny, and hooks. While reviewing diffs remains important, a new layer has emerged that enhances security and prevents incidents. This new layer sits between the code and the review process, and its effectiveness is clearly defined in the documentation.\n\nThe key point is that the documentation separates instructions from enforcement. CLAUDE.md focuses on the instruction side, while permission rules and hooks are the executable components of the review checklist items that a machine can verify. However, permissions alone cannot replace the thorough review process; they simply add an additional layer for automation.\n\nThe documentation explicitly states that settings rules are enforced by the client, regardless of Claude's interpretation. CLAUDE.md instructions guide Claude's behavior but are not a hard enforcement mechanism. If absolute certainty is required, a PreToolUse hook should be used instead, as it blocks actions irrespective of Claude's decisions.\n\nA document containing a project's rules exists, but it is read and followed on a best-effort basis, not as part of the code itself. Regardless of how well the documentation is written, it still falls into a specific category. The distinction between writing a review comment and implementing it into permissions.deny lies in the strength of the enforcement.\n\nPermission design effectively acts as the review checklist made executable. It separates items that require human reading, such as design intent, naming, and abstraction coherence, from those that can be determined by machines, like touching production configuration or credentials reaching logs. These latter items can be expressed as rules.\n\nThe placement of these rules matters. permissions.deny blocks actions before the classifier is consulted, preventing the classifier or user intent from overriding them. permissions.ask, on the other hand, always prompts for a command that matches a content-scoped rule, ensuring a human review is always required. Critical-path removal commands, such as rm and rmdir, are also explicitly blocked by rules and cannot be approved by allow rules or PreToolUse hooks.\n\nPreToolUse hooks are specifically designed to block actions regardless of Claude's judgment. These hooks run independently of Claude's evaluation, providing an additional safety net. The documentation provides examples of using PreToolUse hooks to block specific actions, such as rm -rf, and discusses their limitations.\n\nIn summary, designing allow, deny, and hooks is becoming the new standard for code reviews in teams that rely heavily on coding agents. While code reviews remain essential, this new layer of automation adds an extra level of security and ensures that actions are restricted according to predefined rules, even before the review process begins.",
  "summary": "Originally published at https://aicoding-guide.com . 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…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}