Bash rm -rf executed without permission prompt despite not being in allow list

Bug Description

A Bash(rm -rf ...) command was executed without prompting the user for approval, despite the command not matching any entry in the user's permission allow list.

Steps to Reproduce

1. Configure .claude/settings.local.json with a specific allow list (no wildcard Bash permissions):

{
  "permissions": {
    "allow": [
      "Bash(esphome version:*)",
      "Bash(esphome compile:*)",
      "Bash(ssh:*)",
      "Bash(scp:*)",
      "Bash(curl:*)",
      "Bash(git push:*)",
      "Bash(ping:*)",
      "Bash(gh repo view:*)",
      "Bash(gh issue view:*)",
      "Bash(gh issue create:*)"
    ]
  }
}

1. Global ~/.claude/settings.json is empty: {}

1. In conversation, Claude runs:

rm -rf /Users/username/Projects/project-name/.esphome && echo "Deleted .esphome/ — freed ~1 GB"

1. Expected: User is prompted to approve or deny the command, since rm / rm -rf is not in the allow list.

1. Actual: Command executed immediately without any permission prompt. 1 GB of files were deleted.

Context

• The user had conversationally said "yeah go for it" in response to Claude asking "Want me to nuke it?" — but this was conversational approval, not the permission system's approval gate.
• The allow list has no wildcard Bash(*) or Bash(rm:*) entry.
• rm -rf is a destructive, hard-to-reverse operation that should always require explicit permission system approval unless specifically allow-listed.

Impact

This is a permission bypass for destructive filesystem operations. Even though the outcome was intended in this case (deleting a regenerable build cache), the permission system should have been the enforcement layer, not conversational inference.

Environment

• macOS (Darwin 25.2.0)
• Claude Code CLI
• Permission mode: custom allow list (not yolo/auto-accept)