[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
- Run a specific gcloud subcommand, e.g.:
gcloud scheduler jobs list --project=xxx --location=yyy
- 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.
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Thanks for the duplicate suggestions.
After reviewing all three issues, I believe this is a distinct problem:
My issue is specifically about a single, non-compound command (gcloud scheduler jobs list) being grouped into an overly broad wildcard pattern (gcloud scheduler:*), which risks unintentionally allowing write operations. This appears to be a side effect of the v2.1.59 "per-subcommand prefix" change being applied beyond its intended scope.
I'll keep this open as a separate report.
你的分析完全正確，這確實是獨立的問題。v2.1.59 的 per-subcommand prefix 改動在分組邏輯上過於激進——
gcloud scheduler jobs list這種明確的唯讀操作不應該被歸到gcloud scheduler:*這種涵蓋寫入操作的萬用模式。立即可用的 workaround： 手動編輯
.claude/settings.local.json，將過寬的 wildcard 換成你的 issue 裡提到的精確格式：把：
換成：
這樣只允許你實際執行過的唯讀指令，不會意外開放寫入操作的權限。
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.