Group of 2 You'll notice
The bash auto-allow-when-sandboxed fast path now also blocks commands matched by a new denylist check, though its data source currently returns nothing
What
The 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.
- The same
rz(e.command)check, along with a relatedfsn()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. - Currently, the data source behind this check (
fsn()) is a stub that returns null, so the new check has no practical effect yet.
Why
This 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.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
What specifically the new command-content check looks for is not stated in the finding.