[BUG] `autoAllowBashIfSandboxed` prompts for commands containing `key=value` arguments

[RyanMentley]

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?

With sandbox.enabled: true and autoAllowBashIfSandboxed: true, Bash commands containing either...

• variable assignments, or
• arguments that look like Bash variable assignments (identifier=value where identifier matches [a-zA-Z_][a-zA-Z0-9_]*)

...trigger a permission prompt instead of being auto-allowed.

What Should Happen?

At the very least, this very common shell construct should work without prompting when autoAllowBashIfSandboxed is true.

The point of autoAllowBashIfSandboxed is to allow the agent to work independently, and this prevents that from working. The model has no idea why these prompts are happening (resulting in frustrating hallucinated explanations and non-functional workarounds), and it took several rounds of insistent iteration, including having a model reverse-engineer Claude Code's source, to find out what was causing it.

This is not an edge case:

• FOO=bar some_command to set environment variables is an extremely common way to pass arguments to programs (for example, Claude Code has plenty of environment variables that can be used to configure it).
• xcodebuild, a pretty core Apple development tool, uses an argument format that triggers this behavior.

That said, the sandbox is a safety boundary. There should be a way, even if it's not the default, to allow commands that the static analyzer can't fully understand to be auto-allowed to run inside the sandbox, rather than falling back to a permission prompt. Currently, achieving this would require using the bypassPermissions permission mode, which removes an additional layer of safety beyond what this would permit, as it "skips the permission layer entirely". Additionally, this would not grant the model any access it does not already have, as it can already work around these denials by putting the command into a shell script.

Error Messages/Logs

This command requires approval

Steps to Reproduce

With sandbox enabled and autoAllowBashIfSandboxed true, any Bash command with any variable assignment or any argument matching [a-zA-Z_][a-zA-Z0-9_]*=.* triggers a prompt, regardless of position in the command. Characters that invalidate a bash identifier before the = (digits at start, /, -) suppress the prompt.

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true
  }
}

Command	Prompts?
a=b (standalone assignment)	No
FOO=bar swift --version	Yes
FOO=bar wc -l file	Yes (even though wc is an allowlisted read-only command)
FOO=bar bash script.sh	Yes
python3 hello	No
python3 a=b	Yes
python3 A=b	Yes
python3 -c 'pass' a=b	Yes
python3 1=b	No
python3 a-b=c	No
xcodebuild -version	No
xcodebuild -destination 'platform=iOS Simulator,...'	Yes
xcodebuild -destination 'platform=iOS' -list	Yes
xcodebuild -destination 'foo=bar' -list	Yes
xcodebuild -destination 'generic/platform=iOS' -list	No
xcodebuild -destination 'generic/foo=bar' -list	No
xcodebuild -destination 'platform' -list	No
bash script.sh (script contains a command that triggers a prompt)	No

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.139 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (happens in CLI/zsh/iTerm2 and desktop app)

Additional Information

Workaround: Wrap commands in a shell script.

Related, but not duplicates:

• [BUG] autoAllowBashIfSandboxed bypassed for commands containing shell expansions and several other constructs #43713 (focuses on shell expansions, does not seem to mention variable assignment)
• --permission-mode dontAsk bypasses autoAllowBashIfSandboxed for Bash commands containing shell variable expansion #51001 (just marked fixed, but this bug report was tested in the version with that fix)

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Bash(cmd:*) permission rules don't match commands prefixed with environment variables #49350
2. [BUG] Permission allowlist patterns don't match Bash commands starting with environment variables #15292
3. [BUG] autoAllowBashIfSandboxed bypassed for commands containing shell expansions and several other constructs #43713

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[yurukusa]

The same area got a partial fix in v2.1.139: "Fixed autoAllowBashIfSandboxed not auto-approving commands with shell expansions like $VAR and $(cmd)" addressed the dynamic-shell-expansion case but didn't touch the static KEY=value assignment case your report covers. Same underlying analyzer, different syntax surface.
The bypassPermissions tradeoff you noted is the live workaround until the static analyzer treats IDENTIFIER=value as a recognized prefix that doesn't change the called program's behavior. Wrapping the call in a script does work, with the friction cost you noted (the model has to invent the wrapper from a generic "permission denied" with no diagnostic about what triggered it).
Your "the model has no idea why these prompts are happening" point maps to a broader pattern in this area: permission denials surface as opaque This command requires approval to the model, with no machine-readable reason for which rule fired or why. Hooks can emit richer messages via decision JSON, but the built-in prompt format doesn't carry the analyzer's reasoning out, so the model's "hallucinated explanations and non-functional workarounds" follow predictably.

[mkomel]

Another workaround to this is to put Bash(*) in the allow list in your managed, user or project-level settings:

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

Should be ok, since all bash commands should be auto allowed via autoAllowBashIfSandboxed anyway.

[Amund211]

Another workaround to this is to put Bash(*) in the allow list in your managed, user or project-level settings:

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

Should be ok, since all bash commands should be auto allowed via autoAllowBashIfSandboxed anyway.

This does not work if you have allowUnsandboxedCommands set to true, as the agent could simply ask to run any command outside the sandbox and have it be allowed by this setting - effectively disabling the sandbox.