Bash(gcloud *) allow rule does not match all gcloud subcommands

Bug Description

Bash(gcloud *) in the allow list does not consistently match all gcloud subcommands. Some subcommands still prompt for user approval despite the wildcard rule.

Steps to Reproduce

1. Add Bash(gcloud *) to ~/.claude/settings.json allow list:

{
  "permissions": {
    "allow": [
      "Bash(gcloud *)"
    ]
  }
}

1. Run commands that work (auto-approved):

• gcloud scheduler jobs list --project=... --location=... ✅
• gcloud scheduler jobs run ... --project=... --location=... ✅

1. Run commands that still prompt for approval:

• gcloud scheduler jobs describe ... --project=... --location=... ❌ prompts
• gcloud logging read '...' --project=... --limit=3 ❌ prompts
• gcloud secrets list --project=... ❌ prompts

Expected Behavior

All gcloud subcommands should be auto-approved when Bash(gcloud *) is in the allow list.

Actual Behavior

Certain gcloud subcommands (notably describe, logging read, secrets list) still prompt for user approval. The prompting is inconsistent — gcloud scheduler jobs list works but gcloud scheduler jobs describe does not.

Adding the commands to the deny list does not explain this — they are not in the deny list. The deny list only contains specific patterns like Bash(gcloud auth print-access-token*) and Bash(gcloud secrets versions access*).

Selecting "Yes, and don't ask again" during the prompt does not persist across parallel tool calls or new invocations in the same session.

Environment

• Claude Code CLI
• macOS (Darwin 25.3.0)
• Shell: zsh

Workaround

Use gcloud ... list or gcloud ... run instead of gcloud ... describe where possible. Avoid gcloud logging read and gcloud secrets list.