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

Resolved 💬 5 comments Opened May 12, 2026 by RyanMentley Closed Jun 26, 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?

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:

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:

  • #43713 (focuses on shell expansions, does not seem to mention variable assignment)
  • #51001 (just marked fixed, but this bug report was tested in the version with that fix)

View original on GitHub ↗

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