Description
The block-rm-rf builtin policy is meant to stop catastrophic recursive deletes, but its
target-detection only recognises a narrow "shape" of command. Several everyday ways to
recursively delete critical directories are allowed because the policy pattern-matches
raw command text instead of reasoning about what the shell would actually resolve.
Root cause is in blockRmRf (src/hooks/builtin-policies.ts:634). The "destructive path"
test (:637-640) only treats a token as dangerous when it is exactly /, exactly ~, or a
single-segment absolute path matching ^/[A-Za-z_][\w.-]*$. It never expands shell
variables, never handles home-relative sub-paths, and only knows the literal command rm.
Steps to Reproduce
Enable block-rm-rf and issue any of these Bash commands. Each is currently allowed:
| Command |
Why it slips through |
rm -rf $HOME / rm -rf ${HOME} / rm -rf "$HOME" |
Variable is never expanded; the literal text $HOME matches no destructive-path pattern |
rm -rf ~/Documents |
Starts with ~/…, which isn't exactly ~ and isn't /… |
rm -rf /home/chetan |
Multi-segment absolute path fails the single-segment regex |
find / -delete |
Not an rm command at all — same catastrophic effect, unknown to the policy |
rm -rf $(echo /) |
Command substitution is not evaluated |
Baselines that are correctly blocked (for contrast): rm -rf /, rm -rf /etc, rm -rf ~, rm -rf /*.
Expected Behavior
All of the above should be denied (or, for the allow-list case, only permitted when the
resolved target is under a configured allowPaths entry). At minimum:
- Home-relative deletes (
~/…, $HOME, ${HOME}) should be treated like deletes of the home dir.
- Multi-segment absolute paths (
/home/<user>, /var/lib, …) should count as destructive.
- Non-
rm recursive deleters (find … -delete, find … -exec rm -rf) should be considered.
Failproof AI Version
0.0.14-beta.1
Node.js / Bun Version
Bun 1.3+
Operating System
Linux
Notes for contributors
Good candidate for a focused PR that widens the destructive-path detection and adds table-driven
tests in __tests__/hooks/builtin-policies.test.ts. Shell parsing is genuinely hard — the goal
is to close the common evasions above, not to build a full shell interpreter.
Description
The
block-rm-rfbuiltin policy is meant to stop catastrophic recursive deletes, but itstarget-detection only recognises a narrow "shape" of command. Several everyday ways to
recursively delete critical directories are allowed because the policy pattern-matches
raw command text instead of reasoning about what the shell would actually resolve.
Root cause is in
blockRmRf(src/hooks/builtin-policies.ts:634). The "destructive path"test (
:637-640) only treats a token as dangerous when it is exactly/, exactly~, or asingle-segment absolute path matching
^/[A-Za-z_][\w.-]*$. It never expands shellvariables, never handles home-relative sub-paths, and only knows the literal command
rm.Steps to Reproduce
Enable
block-rm-rfand issue any of these Bash commands. Each is currently allowed:rm -rf $HOME/rm -rf ${HOME}/rm -rf "$HOME"$HOMEmatches no destructive-path patternrm -rf ~/Documents~/…, which isn't exactly~and isn't/…rm -rf /home/chetanfind / -deletermcommand at all — same catastrophic effect, unknown to the policyrm -rf $(echo /)Baselines that are correctly blocked (for contrast):
rm -rf /,rm -rf /etc,rm -rf ~,rm -rf /*.Expected Behavior
All of the above should be denied (or, for the allow-list case, only permitted when the
resolved target is under a configured
allowPathsentry). At minimum:~/…,$HOME,${HOME}) should be treated like deletes of the home dir./home/<user>,/var/lib, …) should count as destructive.rmrecursive deleters (find … -delete,find … -exec rm -rf) should be considered.Failproof AI Version
0.0.14-beta.1
Node.js / Bun Version
Bun 1.3+
Operating System
Linux
Notes for contributors
Good candidate for a focused PR that widens the destructive-path detection and adds table-driven
tests in
__tests__/hooks/builtin-policies.test.ts. Shell parsing is genuinely hard — the goalis to close the common evasions above, not to build a full shell interpreter.