{"version":"2.1.314","anchor":"sandbox-excludedcommands-description-clarified","canonical_anchor":"sandbox-excludedcommands-description-clarified","heading":"Sandbox excludedCommands description now spells out what stays sandboxed","tier":"notice","area":"Sandbox","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314\/e\/sandbox-excludedcommands-description-clarified","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314","markdown":"### Sandbox excludedCommands description now spells out what stays sandboxed\n\nThe `excludedCommands` description now says a call leaves the sandbox only if every command in it matches, and lists cases that stay inside\n\n**What**\n\nThe description of the sandbox `excludedCommands` setting is more precise now. The sandbox is a fenced-off space where commands run with limited access. The description used to say only that matching command patterns always run outside it.\n\nIt now says an entry takes a call out of the sandbox only when every command in the call matches an entry. This includes every part of a pipe or chain. It also lists calls that stay sandboxed:\n\n- `cd`\n\n- command substitution, such as `$(...)`\n\n- redirects other than `2>&1`, including heredocs\n\n**Why**\n\nThe old wording suggested more commands would escape the sandbox than actually do. If you rely on `excludedCommands`, check that your pipes, chains and redirects match these rules.\n\n- Area: Sandbox\n- Names: `excludedCommands`\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}