Allow rules override ask rules, preventing broad allow with specific ask carve-outs

Summary

A blanket Bash entry in allow overrides specific patterns in ask, making ask rules silently ineffective. There is no way to broadly allow Bash commands while requiring confirmation for specific dangerous operations.

Reproduction

1. Add "Bash" to the allow list
2. Add "Bash(git push*)" to the ask list
3. Run git push via Claude Code

Expected: Claude Code prompts for confirmation (ask behavior)
Actual: The command is silently auto-approved (allow behavior)

Example config

{
  "permissions": {
    "allow": ["Bash"],
    "ask": [
      "Bash(git push*)",
      "Bash(rm *)",
      "Bash(docker run*)"
    ],
    "deny": []
  }
}

All three ask patterns are silently bypassed because the blanket Bash allow matches first.

Expected behavior

More specific rules should override less specific ones. At minimum, deny and ask rules should always take precedence over allow rules. An evaluation order of deny → ask → allow (first match wins) would let users write simple configs like the one above, instead of maintaining an exhaustive whitelist of hundreds of safe commands to avoid listing Bash as a blanket allow.

Current workaround

Enumerate every safe command individually in the allow list (900+ lines) and rely on unlisted commands falling through to the default prompt behavior. This is fragile and error-prone — any command not in the whitelist gets prompted even if it's harmless, and the config becomes unmaintainable.

Open question

It is unclear whether allow also overrides deny rules, or only ask. If allow overrides deny as well, the security implications are more severe — users cannot create a hard block on dangerous commands while broadly allowing others.