Auto mode: a PreToolUse hook "allow" should resolve the action like a permissions.allow rule

## Feature request: let a PreToolUse hook `"allow"` resolve an action in auto mode, the way an allow rule does

**Claude Code version:** 2.1.266 (macOS)

### Current behaviour

The auto mode decision order in [permission modes](https://code.claude.com/docs/en/permission-modes) has three steps: (1) a matching allow/ask/deny rule resolves immediately, (2) reads and working-directory edits are auto-approved, (3) everything else goes to the classifier. A PreToolUse hook is not one of those steps. The [hooks reference](https://code.claude.com/docs/en/hooks#pretooluse-decision-control) says `permissionDecision: "allow"` "skips the permission prompt". Auto mode has no prompt, so a hook-approved Bash command still goes to the classifier and can be hard-blocked.

A hook's `"deny"` and `"ask"` are honoured in auto mode. Its `"allow"` is the one decision the classifier overrides.

### Why it matters

Our repository sends every Bash command through one reviewed, tested policy engine. It is a PreToolUse hook shared by Claude Code and another coding agent. The engine checks flag positions and argument shape, and it decides each segment of a compound command separately. Prefix rules in `permissions.allow` cannot express any of that.

Because the classifier cannot see the engine's verdict, the only way to keep an approved command away from the classifier is to write the policy a second time as prefix rules. We did that for our read-only AWS CLI surface, and we had to add a test so the two copies don't drift apart. Auto mode also drops broad allow rules such as interpreter wildcards, so each script needs its own rule.

### Evidence

We rebuilt classifier verdicts from local transcripts. The first window ran 2026-07-22 to 2026-09-01 and covered 99 blocked Bash commands:

- 0 of them matched a `permissions.allow` rule. That fits the documented order: an allow rule keeps a command away from the classifier.
- 3 of them would get an `"allow"` from our PreToolUse policy engine, and the classifier blocked all three.

**Caveat:** those three hook verdicts come from replaying the commands through our policy as it stood on 2026-09-01. They were not captured when the denials happened.

A second window, 2026-09-01 to 2026-09-16, covered 61 blocked Bash commands. None matched an allow rule and none had a hook `"allow"`.

### Ask

One of these:

1. Let a PreToolUse hook `"allow"` resolve the action at step 1 of the decision order, as an allow rule does, and still honour deny/ask rules, protected paths and critical-path removals. This could be opt-in: a setting, or a field such as `"resolvesAutoMode": true` in the hook output.
2. Or provide a supported way to register repository policy that the classifier consults.
3. At minimum, have the hooks reference say explicitly that a hook `"allow"` does not skip classifier review in auto mode.

### Related

- Denial telemetry, our other gap, is now covered by the `PermissionDenied` hook and its `reason` field. #72589 tracks the structured denial type.
- #89561 covers the hook `"ask"` decision in auto mode. #88604 covers `ask` rules.

Start with the permission modes documentation and the hooks reference, then reproduce an auto-mode Bash command whose PreToolUse hook returns "allow" and observe the classifier decision. Define and test the selected behavior for hook allow, while preserving deny/ask handling, protected paths, and critical-path removals.

Written by the indexing model from the issue text.