permissions.ask does not fire for Bash commands under sandbox.autoAllowBashIfSandboxed: true

Bug description

permissions.ask rules for Bash(...) patterns do not fire for commands executed under sandbox.autoAllowBashIfSandboxed: true. The command runs immediately with no confirmation prompt, as if the ask rule didn't exist.

This contradicts the documented behavior at https://code.claude.com/docs/en/sandboxing.md ("Sandbox modes" section), which states:

Even in auto-allow mode, the following still apply: - Explicit deny rules are always respected - Content-scoped ask rules like Bash(git push *) still force a prompt even for sandboxed commands

Environment

• Claude Code version: 2.1.207
• OS: Ubuntu 24.04.3 LTS under WSL2 (6.18.33.1-microsoft-standard-WSL2)
• Relevant settings (~/.claude/settings.json):

\\\json
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true
},
"permissions": {
"ask": [
"Bash(git push *)"
],
"deny": [
"Bash(git push --force *)"
]
}
}
\\\

Steps to reproduce

1. Set the config above (sandbox enabled, autoAllowBashIfSandboxed: true, and a content-scoped permissions.ask rule for a Bash(...) pattern).
2. In a Claude Code session, run a Bash command matching the ask pattern (e.g. git push --dry-run, which matches Bash(git push *)).

Expected behavior

Per the sandboxing docs, the content-scoped ask rule should force an interactive confirmation prompt before the command runs, even though it's capable of running inside the sandbox.

Actual behavior

The command executes immediately with zero confirmation prompt — indistinguishable from the pattern not being in permissions.ask at all. Reproduced twice in the same session (git push --dry-run run twice, no prompt either time).

By contrast, moving the same pattern from permissions.ask to permissions.deny does reliably block the command (confirmed working) — so deny correctly overrides autoAllowBashIfSandboxed, but ask does not, despite docs stating both should take precedence over auto-allow.

Impact

This makes permissions.ask unusable as a "require confirmation" control for any Bash pattern when sandbox.autoAllowBashIfSandboxed: true is set — which is a fairly common sandbox configuration. Users following the documented pattern to gate sensitive commands (e.g. git push, gh pr create, gh pr merge) behind a confirmation prompt instead of a hard block get silent full access instead, with no error or warning that the rule isn't taking effect. We worked around this by using hard deny instead, but that removes the ability to approve the action on a case-by-case basis, which was the point of using ask over deny.

Doc reference

https://code.claude.com/docs/en/sandboxing.md — "Sandbox modes" section, precedence order deny > content-scoped ask > auto-allow.