Deny permission rules not blocking commands, falling through to ask

Description

Deny rules in ~/.claude/settings.json are not enforced. Commands that match a deny pattern are not blocked — instead they fall through to the ask confirmation prompt.

Configuration

~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(ls *)",
      "Bash(ls)",
      "Bash(cat *)",
      "Bash(head *)",
      "Bash(tail *)",
      "Bash(find *)",
      "Bash(grep *)",
      "Bash(rg *)",
      "Bash(sed *)",
      "Bash(awk *)"
    ],
    "allow": [
      "Read",
      "Glob",
      "Grep",
      ...
    ],
    "ask": [
      "Bash(*)",
      "Edit(*)",
      "Write(*)",
      "NotebookEdit(*)"
    ]
  }
}

Steps to reproduce

1. Add Bash(ls *) and Bash(ls) to the deny list in ~/.claude/settings.json
2. Add Bash(*) to the ask list
3. Start a Claude Code session
4. Verify rules are loaded via /permissions — deny tab shows Bash(ls *) and Bash(ls) correctly
5. Have Claude attempt to run ls -d /some/path/*/

Expected behavior

The command is hard-blocked immediately. No confirmation prompt is shown.

Actual behavior

The command is not blocked. Instead, a confirmation prompt is shown (ask behavior), as if the deny rule does not exist:

Bash command
  ls -d /Users/.../mcp-servers/*/
  List subdirectories

Permission rule Bash requires confirmation for this command.

Do you want to proceed?

Analysis

• The deny rules are correctly loaded and visible in /permissions
• Per the docs, deny rules evaluate first: "Rules are evaluated in order: deny -> ask -> allow. The first matching rule wins, so deny rules always take precedence."
• The glob pattern ls * should match ls -d /some/path/*/
• The deny rule is being skipped and the generic Bash(*) ask rule is matching instead

Environment

• macOS (Darwin 25.3.0)
• Claude Code with Claude Opus 4.6