Skip to content

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

@naichilab

Description

@naichilab

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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:*

Image

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
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions