{"version":"2.1.309","anchor":"sandbox-auto-allow-also-suspended-when-a-held-file-turned-th","canonical_anchor":"sandbox-auto-allow-also-suspended-when-a-held-file-turned-th","heading":"Settings that switch the sandbox on are now tracked, and can pause sandbox auto-allow","tier":"notice","area":"Sandbox","scope":"both","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309\/e\/sandbox-auto-allow-also-suspended-when-a-held-file-turned-th","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309","markdown":"### Settings that switch the sandbox on are now tracked, and can pause sandbox auto-allow\n\nClaude Code now notes when seeded or held settings turn the sandbox on, and pauses automatic approval of sandboxed commands in that case\n\n**Unclear.** It is not stated what a held file is or how it turns the sandbox on.\n\n**What**\n\nThe sandbox is a restricted environment in which Claude Code can run shell commands, and settings files can switch it on. This release changes what happens when settings turn the sandbox on:\n\n- When project settings are set up (seeded), Claude Code now notices if the settings in the local settings slot turn the sandbox on. It records this as `sandboxTurnedOn` and keeps those settings from being skipped as they otherwise would be. The setup step now takes a callback and a flag, and one settings path is skipped when the flag is not set.\n\n- Sandbox auto-allow is the automatic approval of commands because they run inside the sandbox. It is now also suspended (`sandboxAutoAllowSuspended`) when a held settings file is what turned the sandbox on (`sandboxTurnedOnByHeldFile`).\n\n**Why**\n\nIf a project's settings switch the sandbox on, Claude Code no longer treats that as a reason to approve commands on its own. In that situation you may be asked to approve Bash commands that would otherwise have run without a prompt.\n\n- Area: Sandbox\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 2\/5\n- Scope: both\n- Heads-up: yes"}