The Approval Boundary: Permissions, Sandboxes, and Policy

Security review can tell Claude Code that an action looks dangerous, but it does not answer whether the action should be allowed in the first place. This chapter compares project-local Hookify rules with managed settings, permission modes, and sandbox controls. The practical question is proportionality: when is a warning enough, when must an action be blocked or approved by a person, and when does a policy need to constrain the environment rather than the model’s judgment?

Warning, blocking, and containment are different decisions

Hookify makes the local end of this comparison concrete. A project places a rule in its .claude directory, names an event such as Bash or file editing, supplies a regular expression or set of conditions, and chooses warn or block. The rule can take effect on the next tool use without restarting. That immediacy is useful when a team is learning its own hazards: warn about a sensitive file, block a destructive command, or require evidence of a test before the session stops.

A warning and a block have different meanings even when they use the same pattern. A warning says the operation may proceed, but the person or agent should reconsider it. This is appropriate when the context matters and the action is reversible. A block says the matched operation should not run through that event. This is appropriate when the risk is easy to recognize and the consequence is unacceptable or difficult to undo. Neither action answers every question. A block can be too broad and frustrate legitimate work; a warning can be ignored or arrive after a side effect.

Timing is part of the decision. Hookify wires handlers to pre-tool, post-tool, stop, and prompt events. A pre-tool block can prevent a matched operation before execution. A post-tool message can only influence the next step. A stop hook can refuse to let a session end while a completion condition is missing, but it cannot prove that all earlier work was correct. A rule that says “tests must appear in the transcript” verifies a signal about process, not the quality or coverage of the tests themselves.

flowchart LR A["Requested action"] --> B["Local rule"] B --> C{"Warn or block?"} C -->|"warn"| W["Warned"] C -->|"block"| X["Blocked"] W --> P["Permission decision"] P --> M["Managed policy"] M --> S["Sandbox boundary"] S --> Q{"Allowed?"} Q -->|"yes"| Y["Allowed"] Q -->|"no"| X

The diagram separates several decisions that are often compressed into “the agent was allowed to act.” A local rule can warn or block. A permission decision can still require a person or deny the operation. Managed policy can restrict the choices a local user or plugin has. A sandbox can contain a class of commands without becoming a universal boundary. The final “allowed” state means that the action passed the controls represented here; it does not mean that the action was wise, secure, or fully understood.

The local rule is therefore best for local policy. It can express a repository convention quickly and give a team a visible place to tune patterns. It is not automatically the right location for an organization-wide requirement. A developer can change or delete a local rule, and the rule can only match the event data it receives. If the requirement must survive a project’s customization, it needs a stronger owner or another enforcement point.

The same operation can justify different responses in different contexts.