[BUG] sandbox.autoAllowBashIfSandboxed: true from server-managed settings is not applied — all non-allowlisted commands prompt

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?

• Every Bash command not matching a permissions.allow rule triggers the generic permission dialog:

```
Bash command

java -version

This command requires approval

Do you want to proceed?
❯ 1. Yes

1. Yes, and don't ask again for: java *
2. No

```

• ctrl+e ("explain") on the dialog shows "Explanation unavailable".
• Auto-allow is effectively never engaged: across many sessions, the only commands that ran without prompting were ones matching explicit allow rules (or bare variable assignments).

What Should Happen?

Per the sandboxing documentation, with auto-allow mode enabled, sandboxed Bash commands should run without permission prompts:

Auto-allow mode: Bash commands will attempt to run inside the sandbox and are automatically allowed without requiring permission.

A simple literal command such as java -version or uname -a (no shell expansions — i.e. not issue #43713) should auto-run inside the sandbox.

Error Messages/Logs

Steps to Reproduce

1. In a Claude.ai org with server-managed Claude Code settings, deliver a sandbox block with enabled: true, autoAllowBashIfSandboxed: true, allowUnsandboxedCommands: false, plus a permissions.allow list of read-only commands.
2. Start a fresh claude session in any project on macOS.
3. Ask Claude to run a simple literal command not on the allowlist, e.g. java -version or uname -a.
4. Observe the "This command requires approval" prompt instead of auto-allowed sandboxed execution.
5. Run /sandbox — observe the panel is locked with the higher-priority-configuration error, making the resolved mode uninspectable.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.175

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Configuration (relevant excerpts from the effective server-managed settings)

{
  "allowManagedPermissionRulesOnly": false,
  "permissions": {
    "allow": ["Bash(ls:*)", "Bash(cat:*)", "Bash(grep:*)", "Bash(echo:*)", "..."],
    "ask": [],
    "defaultMode": "default",
    "deny": ["Bash(sudo:*)", "Bash(curl:*)", "..."]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "excludedCommands": ["docker *"],
    "filesystem": { "allowManagedReadPathsOnly": true, "denyWrite": ["..."] },
    "network": { "allowManagedDomainsOnly": false, "allowedDomains": [] }
  }
}

User settings (~/.claude/settings.json) also contain sandbox.autoAllowBashIfSandboxed: true. No project-level .claude/ settings exist. ~/.claude/settings.local.json is empty.

Verified facts (things ruled out)

1. The sandbox itself is active and enforcing. A probe (echo test > /tmp/probe) executed and was blocked at the OS level with operation not permitted (/tmp is outside the allowed write paths) — so this is not a sandbox-failed-to-initialize fallback (failIfUnavailable: false).
2. The setting key is valid. sandbox.autoAllowBashIfSandboxed exists in the published settings JSON schema (default true).
3. Not a managed-permissions lockdown. allowManagedPermissionRulesOnly is false (it was true earlier; changing it to false made no difference to this behavior).
4. Not shell-expansion related (#43713). Plain literal commands (java -version, javac -version, uname -a) prompt.
5. Not the IDE extension (#64061). Reproduced in plain iTerm and Terminal.app.
6. No lower-scope override. No project .claude/ directory; user-level settings.local.json empty; both user and managed scope say autoAllowBashIfSandboxed: true.
7. /sandbox panel cannot be opened: it errors with

Error: Sandbox settings are overridden by a higher-priority configuration and cannot be changed locally.
so there is no way to inspect the resolved mode or confirm which tier wins.

Suspected cause

Auto-allow mode appears to be suppressed whenever the sandbox configuration is delivered through the managed/server tier. The /sandbox panel lock message suggests the managed tier takes over sandbox configuration entirely, but the autoAllowBashIfSandboxed: true value inside that same managed config is then not honored — the session behaves as "regular permissions" mode.

Impact

Organizations that centrally enforce sandboxing (enabled: true, allowUnsandboxedCommands: false) — the exact deployment pattern recommended in the "Configure the sandbox for your organization" docs — cannot get auto-allow, resulting in a permission prompt for every command outside the managed allowlist. This combines the friction of regular-permissions mode with none of the autonomy the sandbox is meant to enable.