PreToolUse hook 'allow' cannot bypass Bash sensitive path ask rules (unlike Edit/Write)

Description

When a PreToolUse hook returns permissionDecision: "allow" for a Bash command targeting a sensitive path (e.g. ~/.claude/), the built-in ask rule overrides the hook decision and still prompts the user. The same hook allow response successfully bypasses the prompt for Edit/Write tools.

Debug log evidence

Edit (works — bypasses prompt):

Hook approved tool use for Edit, bypassing permission prompt

Bash (doesn't work — still prompts):

Hook approved tool use for Bash, but ask rule requires prompt

Both hooks return identical JSON:

{"hookSpecificOutput": {"hookEventName": "PreToolUse", "permissionDecision": "allow"}, "systemMessage": "..."}

We also tested with updatedInput included (echoing back tool_input), which sometimes produces "bypassing permission prompt" but inconsistently.

We verified with a hardcoded hook that always returns allow with updatedInput and systemMessage — same result: "but ask rule requires prompt".

Root cause

In FO7, after a hook returns allow, the code calls QO7(_, Y, K) to check for overriding permission rules. For Edit/Write, QO7 returns null (no override → bypass). For Bash on sensitive paths, QO7 returns an ask rule that overrides the hook.

Question

Is this intentional security hardening for Bash, or should hook allow decisions be able to bypass Bash sensitive path ask rules the same way they do for Edit/Write?

Use case

We have a CODEOWNERS-AGENTS plugin that auto-allows file operations in directories owned by the current agent. The Edit/Write hook works perfectly. We want the same behavior for Bash commands (e.g. mkdir, rm) in owned directories.

Environment

• Claude Code 2.1.97
• macOS