Bash "ask" rules stop prompting under --dangerously-skip-permissions, contradicting the documentation

Expected behavior (per code.claude.com/docs/en/permissions and code.claude.com/docs/en/permission-modes)

• An ask rule wins over an allow rule: "a matching ask rule prompts even when a more specific allow rule also matches the same call".
• Bypass does not override ask: "Claude Code doesn't auto-approve the following in any mode, including bypassPermissions", with "Tools matched by an explicit ask rule" as the first item in the list. Also: "Allow rules have no effect in bypassPermissions".
• There is no documented exception for Bash. The listed exceptions are EndConversation and organization connectors.
• Ask/deny rules match even behind a variable prefix: "A deny or ask rule matches past any leading assignment". The docs also warn that ask/deny rules match the command text and that this "isn't a security boundary around the program".

Observed behavior

• With the rules below loaded and visible in /permissions (Ask tab, all 21 rules complete and correct), commands that match them run with NO prompt at all.
• Inconsistency: on the same day, with the same configuration, a plain git push did pause ("Permission rule Bash(git push*) requires confirmation for this command"), and in one round of tests psql by full path and DATABASE_URL=... npx prisma migrate also paused. After an edit to the rules file (17:33), nothing paused anymore, not even the controls anchored at the start of the command.
• Tested and ruled out: approval cache (psql --version 5 times in a row, no change), mode switch (18 permission-mode events, all bypassPermissions), permission environment variables, managed-settings, invalid rules (claude doctor clean), and incomplete reloading of the rules.
• Reproduced in a genuinely new session (new process, new session ID), with no rule edits, with /permissions showing the correct rules.
• Anticipated objection: the docs list, in the table under "A Bash rule matches the command text", that Bash(git push *) does not cover git -C . push origin main, and that a rule doesn't cover "the same program invoked in a different form". That does NOT explain this case, because the rules used here were written to cover exactly those forms, and each test command matches rules in the list:
• a) ~/.local/bin/psql --version matches Bash(*psql*). (A control without a path, psql --version, matches Bash(psql*) and also did not pause.)
• b) git -C <repo> push remoto-que-nao-existe main matches Bash(git -C *) and Bash(*git*push*).

So the commands are not a "different form" relative to the rules: they are matched by them directly.

Steps to reproduce

1. Start: claude --dangerously-skip-permissions
2. A .claude/settings.local.json with, among others:

``
"ask": ["Bash(git commit*)", "Bash(git push*)", "Bash(npx prisma migrate*)",
"Bash(psql*)", "Bash(rm*)", "Bash(*git*commit*)", "Bash(*git*push*)",
"Bash(*prisma migrate*)", "Bash(*psql*)", "Bash(git -C *)",
"Bash(git -c *)", ...] (21 rules in total)
`
Note: the project's .claude/settings.json has a broad allow list (60 rules, including Bash(git ), Bash(git commit) and Bash(npx prisma migrate*)) and defaultMode: "bypassPermissions"`.

1. Ask the assistant to run, one at a time:

a) ~/.local/bin/psql --version
b) git -C <repo> push remoto-que-nao-existe main

1. Result: neither asks for confirmation. (a) prints psql (PostgreSQL) 17.11 (Postgres.app); (b) fails with fatal: 'remoto-que-nao-existe' does not appear to be a git repository, exit code 128.

Environment

• Claude Code 2.1.278, macOS (Darwin), zsh
• Flag: --dangerously-skip-permissions
• Rules in .claude/settings.local.json (ask) and .claude/settings.json (allow), both project-level

Impact

• Ask rules used as a safety net (git push, prisma migrate, psql, rm) are not reliable. The user now depends only on a behavioral rule in CLAUDE.md.

Questions

• Does ask under --dangerously-skip-permissions have an undocumented exception for Bash?
• Is the intermittent behavior (paused, then stopped pausing, same syntax) known?