[BUG] /sandbox Mode tab shows "regular permissions" as selected when runtime and persisted settings are auto-allow (v2.1.173, refile of #47624)

Summary

In Claude Code v2.1.173, the /sandbox panel's Mode tab shows the checkmark on option 2 ("Sandbox BashTool, with regular permissions") even though the effective runtime mode is demonstrably auto-allow (option 1). Selecting option 1 persists correctly — the project's .claude/settings.local.json is written with sandbox: {"enabled": true, "autoAllowBashIfSandboxed": true}, exactly as documented at https://code.claude.com/docs/en/sandboxing — but on reopening the panel, the indicator still marks option 2 as selected.

This is a refile of #47624 (same symptom in the pre-tab picker UI at v2.1.105, where the label was (current) rather than a checkmark). That issue was auto-closed not_planned by the stale bot on 2026-05-24 with no maintainer triage, and the bot invited a new issue if still relevant. It is: the CHANGELOG between 2.1.105 and 2.1.173 contains no entry fixing the mode indicator (the only /sandbox UI entry in that range is a spacing fix in 2.1.147), and the bug reproduces in the current tabbed UI.

Environment

• Claude Code: v2.1.173 (verified via claude --version)
• macOS (Darwin 25.5.0), Seatbelt sandbox functional
• No managed settings

Reproduction

1. Configure ~/.claude/settings.json with a customised sandbox block:

enabled: true, failIfUnavailable: true, autoAllowBashIfSandboxed: true,
allowUnsandboxedCommands: false, network.allowedDomains: [...],
filesystem.allowWrite/denyRead: [...], excludedCommands: ["gh *"].

1. Start a session, run /sandbox, select option 1 ("Sandbox BashTool, with auto-allow").

The status banner correctly reports: ✓ Sandbox enabled with auto-allow for bash commands.

1. Confirm persistence: the project's .claude/settings.local.json mtime updates and the file

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

1. Confirm runtime: any benign Bash command runs sandboxed without a permission prompt.
2. Reopen /sandbox (same session or a fresh one) → the Mode tab shows the checkmark on

option 2, "Sandbox BashTool, with regular permissions".

Expected

The Mode tab's selected-state indicator reflects the effective (merged) sandbox mode — which is derived from enabled + autoAllowBashIfSandboxed, both true at the user-global and project layer.

Actual

The indicator marks "regular permissions" regardless. Persistence and runtime are correct; only the indicator is wrong.

Hypothesis

The indicator appears to pattern-match the resolved sandbox config against fixed presets rather than evaluating the derived mode. A sandbox block customised with additional fields (failIfUnavailable, allowUnsandboxedCommands: false, network, filesystem, excludedCommands) matches no preset and falls through to the option-2 rendering. Notably, the docs themselves recommend several of these customisations (e.g. adding credential paths to denyRead), so the hardened-config case is the one the indicator gets wrong.

Impact

Cosmetic, but misleading: users who hardened their sandbox per the docs see the weaker mode displayed, conclude auto-allow is off, and burn time reconfiguring or re-investigating (this is my second full investigation of the same symptom across two UI generations).

Related

• #47624 — predecessor report (v2.1.105, pre-tab picker), stale-closed not_planned without triage
• #43713 — autoAllowBashIfSandboxed bypassed for commands containing shell expansions (open)
• #58214 — autoAllowBashIfSandboxed prompts for commands containing key=value arguments (open)
• #44791 — /model silently wipes sandbox allowlist (sibling: slash-command vs sandbox state)