[BUG] v2.1.59: "Always allow" suggests overly broad wildcard instead of specific subcommand

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Since v2.1.59, the "Yes, and don't ask again for:" option suggests an overly broad wildcard pattern instead of the specific command that was executed.

For example, running gcloud scheduler jobs list results in the following option being offered:
> Yes, and don't ask again for: gcloud scheduler:*

<img width="407" height="125" alt="Image" src="https://github.com/user-attachments/assets/cfe3d374-cf0d-473d-abc2-8ef6fd430a90" />

The wildcard gcloud scheduler:* also covers write operations (e.g. gcloud scheduler jobs create, gcloud scheduler jobs delete), which the user never intended to allow. Users may unintentionally grant broader permissions than desired.

What Should Happen?

The prompt should suggest the specific subcommand that was executed, e.g.:
> Yes, and don't ask again for: gcloud scheduler jobs list

This is consistent with the likely previous behavior — existing entries in .claude/settings.local.json such as

"Bash(gcloud scheduler jobs list:*)" suggest the old behavior recorded specific subcommands.

Error Messages/Logs

Steps to Reproduce

1. Run a specific gcloud subcommand, e.g.:

gcloud scheduler jobs list --project=xxx --location=yyy

1. Observe option 2 in the permission prompt:

"Yes, and don't ask again for: gcloud scheduler:*"

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.61 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

The v2.1.59 changelog states:
"Improved 'always allow' prefix suggestions for compound bash commands to compute smarter per-subcommand prefixes instead of treating the whole command as one"

This change appears to affect single commands with subcommand structure (not just compound commands with &&), resulting in unintended over-permissioning.