Sandbox excludedCommands only come from trusted settings when unsandboxed commands are forbidden
Under a strict sandbox policy, project settings can no longer exclude commands from the sandbox, and adding an exclusion goes to user settings or is refused
You'll noticeTier: how much it should matter to you
2Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
SandboxArea: what it touches
ImprovementsKind: in v2.1.282,
ImprovementsSection of the release
What
sandbox.excludedCommands lists commands Claude Code may run outside the sandbox (the restricted environment that limits what commands can touch). When unsandboxed commands are forbidden, this list is now read only from trusted settings.
Entries are then read only from managed settings, --settings and user settings. Entries in project .claude/settings.json and .claude/settings.local.json are dropped, and a debug line once per session says how many were ignored. The setting's description now states this.
Adding an exclusion under that policy writes it to user settings instead of local settings.
If user settings are turned off (for example with --setting-sources), adding an exclusion is refused with the code user_settings_disabled and a "Can't exclude" error explaining there is no settings file where it would take effect. Before, it was saved where it had no effect and the command reported success.
This has no feature switch.
Why
Before, a repository could list commands in its own settings file and run them outside a sandbox the administrator had made mandatory. The add command also stops claiming success for an exclusion that does nothing. If your project relies on excludedCommands under such a policy, move those entries to user settings or ask your administrator.
