Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Bash(cmd:*) permission rules don't match commands prefixed with environment variables [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49350•Fetched 2026-04-17 08:43:41
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
akre54akre54
Participants
akre54akre54github-actions[bot]github-actions[bot]
Timeline (top)
labeled ×5commented ×1subscribed ×1

Fix Action

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.

Code Example

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

---

AWS_PROFILE=my-profile aws s3 ls

---

"Bash(AWS_PROFILE=my-profile:*)"
RAW_BUFFERClick to expand / collapse

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?

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.

extent analysis

TL;DR

Update the permission rules in settings.json to account for environment variable assignments prefixing the command.

Guidance

  • Review the current permission rules in settings.json and identify patterns that may not match due to environment variable prefixes.
  • Consider adding rules that explicitly match common environment variable prefixes, such as AWS_PROFILE.
  • Test the updated rules with various commands and environment variable prefixes to ensure they are working as expected.
  • Explore the possibility of using a more flexible matching pattern, such as a regular expression, to simplify the rules and reduce maintenance.

Example

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

This example adds a new rule that matches commands prefixed with AWS_PROFILE= and then aws.

Notes

The current implementation of permission rules seems to be based on exact string matching, which may not be sufficient for handling environment variable prefixes. A more robust solution might involve modifying the underlying matching logic to ignore or account for these prefixes.

Recommendation

Apply a workaround by adding more specific rules to settings.json, as the issue is not clearly related to a specific version that can be upgraded to fix the problem. This approach, although fragile, can provide a temporary solution until a more comprehensive fix is available.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

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

#api#optimization#mixed precision#training loop#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING