{"version":"2.1.285","anchor":"sandboxmanaged-settings-descriptions-for-denyread-and-netwo","canonical_anchor":"sandboxmanaged-settings-descriptions-for-denyread-and-netwo","heading":"Sandbox settings descriptions explain which settings file wins","tier":"notice","area":"Sandbox","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.285\/e\/sandboxmanaged-settings-descriptions-for-denyread-and-netwo","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.285","markdown":"### Sandbox settings descriptions explain which settings file wins\n\nSandbox setting descriptions now explain how managed, --settings, user and project settings combine, including allowUnsandboxedCommands\n\n**Unclear.** It is not clear whether this is only descriptive text or whether this release also enforces these rules.\n\n**What**\n\nThe sandbox is the protection that limits which files and network addresses Claude Code's commands can reach. The built-in descriptions of its settings were expanded:\n\n- `sandbox.enabled` now reads \"Run Bash commands inside the sandbox. Default: false.\"\n\n- `ignoreViolations` and `enableWeakerNestedSandbox` gain descriptions, including a Linux-only option to run without the fresh \/proc mount.\n\n- `allowUnsandboxedCommands`: a `false` set in managed settings, a `--settings` file or user settings holds, and in some cases a project-level value is ignored.\n\n- `overrides_locked` is now described as true also when `allowUnsandboxedCommands: false` comes from a `--settings` file or user settings, not only from an admin policy.\n\n- Project settings cannot re-open paths that another layer denies for reading, and a project-level `network.strictAllowlist` value is ignored in some cases.\n\n**Why**\n\nThese are descriptions, not new behaviour. They make it clearer that a project's own settings file cannot loosen sandbox limits set by your administrator, a `--settings` file or your own user settings.\n\n- Area: Sandbox\n- Names: `--settings`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}