ask permission rules are silently ignored in interactive sessions while deny rules from the same file are enforced

Summary

ask permission rules are silently ignored in interactive sessions, while deny rules declared in the same file, in the same session, are enforced normally.

Environment

• Claude Code 2.1.220
• macOS (Darwin 25.5.0), arm64
• Interactive CLI session (claude, no flags), permission mode default
• Settings file: ~/.claude/settings.local.json
• Declaration level: project-local. The session's cwd is the user's home directory, which is not a git repository, so per the docs the local settings file "stays in the directory you start Claude Code from".

Settings (abridged)

{
  "permissions": {
    "allow": ["Bash", "Read", "WebSearch", "WebFetch"],
    "deny":  ["Bash(dd:*)", "Bash(sh)", "Bash(bash)", "Bash(zsh)"],
    "ask":   ["Bash(ssh:*)", "Bash(chmod:*)", "Bash(rm:*)", "Bash(sudo:*)"]
  }
}

Expected

Commands matching an ask rule prompt for confirmation before running.

Actual

They run immediately, with no prompt. deny rules in the same file, same session, are enforced normally.

Reproduction

1. Start an interactive session with cwd = the directory containing the settings file above.
2. Run dd --version → correctly blocked: Permission to use Bash with command dd --version has been denied. (the transcript records "toolDenialKind": "permission-rule")
3. Run echo id | sh → correctly blocked by Bash(sh), so compound-command splitting works.
4. Run ssh no-such-host.invalid "id" → runs, no prompt.
5. Run chmod +x /tmp/probe.sh → runs, no prompt.

Two different ask rules are ignored, so this is not specific to one rule or to argument matching. Adding flags (ssh -o BatchMode=yes …) makes no difference; the bare form is equally unprompted.

Control that isolates it to interactive sessions

With the same settings file, the same cwd, and the same binary, a non-interactive run —

claude -p 'run: ssh no-such-host.invalid "id"'

— is blocked by the permission layer. So the rule text, the file, and rule matching are all fine; only the interactive session fails to apply ask.

Scope of verification

This was verified only for sessions started in the user's home directory, where the settings file above is in effect. It was not tested from another project directory, so whether the behaviour is directory-dependent is unknown.

Impact

ask is the level users put destructive-but-legitimate commands at (rm, sudo, chmod, ssh, git push, docker rm). Those run unprompted with no error and no log line, so the failure is silent — the user believes a confirmation gate exists where there is none.

Possible lead (unverified)

The allow list contains a bare "Bash" entry. A precedence bug where a broad allow short-circuits ask — while deny, checked earlier, still wins — would fit the observations. But the -p control above contradicts a pure precedence explanation, since that run reads the same allow list and still honours ask.