[BUG] Bash(cmd:*) permission rules don't match commands prefixed with environment variables

Resolved 💬 3 comments Opened Apr 16, 2026 by akre54 Closed Apr 20, 2026

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?

Bash permission allow rules fail to match commands that are prefixed with inline environment variable assignments, even when the underlying command matches the pattern.

Expected behavior

Bash(aws:*) should match any bash command where aws is the effective executable, regardless of leading VAR=value env var assignments.

Actual behavior

The rule matches on the raw command string. Since the string starts with AWS_PROFILE= rather than aws, no rule matches and a new permission prompt is shown. Over time this creates a sprawling list of nearly-identical specific allow entries in settings.json.

Steps to Reproduce

Add this to settings.json:

{
  "permissions": {
    "allow": ["Bash(aws:*)", "Bash(deadline:*)"]
  }
}

Then run a command like:

AWS_PROFILE=my-profile aws s3 ls

Claude prompts for permission approval instead of matching the Bash(aws:*) rule.

Environment

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.104 (also on Claude Desktop)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related

  • #45469 (docs gap around env-var prefix matching)

Workaround

Add a rule matching the env var prefix instead:

"Bash(AWS_PROFILE=my-profile:*)"

This works but is fragile — any new VAR=value prefix requires another rule.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗