{"version":"2.1.277","anchor":"bash-auto-allow-when-sandboxed-gets-an-extra-command-content","canonical_anchor":"bash-auto-allow-when-sandboxed-gets-an-extra-command-content","heading":"Bash sandbox auto-allow gets a new command-content check","tier":"notice","area":"Bash Safety","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/bash-auto-allow-when-sandboxed-gets-an-extra-command-content","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Bash sandbox auto-allow gets a new command-content check\n\nThe bash auto-allow-when-sandboxed fast path now also blocks commands matched by a new denylist check, though its data source currently returns nothing\n\n**Unclear.** What specifically the new command-content check looks for is not stated in the finding.\n\n**What**\n\nThe fast path that automatically allows a Bash command to run without confirmation when it's sandboxed now has an extra check. In addition to the existing sandbox and read-outside-current-directory checks, it now also bails out (refuses to auto-allow) when a new function, `rz(e.command)`, returns true for the command.\n\n- The same `rz(e.command)` check, along with a related `fsn()` lookup for substrings and commands that should always be blocked, is also consulted by a broader excluded-command check, not just the sandboxed auto-allow path.\n\n- Currently, the data source behind this check (`fsn()`) is a stub that returns null, so the new check has no practical effect yet.\n\n**Why**\n\nThis wires in the plumbing for blocking specific commands or command substrings from being auto-allowed in a sandbox, even though the actual denylist data isn't populated yet. Until `fsn()` returns real data, this change does not change what gets auto-allowed in practice.\n\n- Area: Bash Safety\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}