permissions.deny (Bash(curl *)) silently bypassed under Auto Mode

Summary

An explicit permissions.deny rule for a Bash command is not enforced while Auto Mode is active, but is correctly enforced in manual mode — same machine, same settings.json, only the permission mode differs.

Environment

• macOS (Darwin), Claude Code CLI v2.1.239, installed via curl -fsSL https://claude.ai/install.sh | bash
• Also reproduced separately via Claude Desktop's bundled Claude Code (Auto Mode active there too)

~/.claude/settings.json (relevant excerpt)

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)"
    ],
    "defaultMode": "default"
  }
}

Steps to reproduce

1. With the above deny rule in place, start a session with Auto Mode on.
2. Ask Claude to run: curl https://example.com via the Bash tool.
3. Observe: the command executes successfully and returns the real HTTP response — no denial, no prompt.
4. Toggle Auto Mode off (Shift+Tab to manual mode) in the same session, same settings.json.
5. Ask Claude to run the identical command again.
6. Observe: the command is now correctly denied by the Bash(curl *) rule, as expected.

Expected behavior

A permissions.deny entry should be a hard stop regardless of permission mode (or at minimum, Auto Mode should not be able to silently override an explicit deny rule the user configured).

Actual behavior

Auto Mode's classifier appears to override the static deny rule for at least this case (curl to a benign-looking domain), executing a command that is explicitly denied in settings.json. This was consistently reproducible across two separate installs/sessions (Claude Desktop's bundled CLI, and a fresh standalone terminal CLI install) on the same machine.

Why this matters

This defeats the purpose of permissions.deny as a hard security boundary for anyone relying on Auto Mode — network-egress and other explicit deny rules should not be quietly negotiable by a classifier layered on top of the static permission config.