What happened?
Denying the launch-process tool via toolPermissions does not prevent file deletion: the agent transparently falls back to the dedicated remove-files tool and deletes the file anyway.
A security-conscious user who denies launch-process (the obvious "run any shell command" tool) to block destructive operations like rm gets a false sense of safety — there is no single rule, group, or category that blocks "delete a file," and the fallback happens silently.
Verified on auggie 0.28.0 (commit 63537d73).
$ auggie --print --max-turns 5 --permission "launch-process:deny" \
-i "Delete the file canary.txt from this workspace."
🔧 Tool call: remove-files
📋 Tool result: remove-files
File(s) removed: canary.txt
The file `canary.txt` has been successfully deleted from the workspace.
canary.txt is gone, despite launch-process being denied. (If I instruct it to specifically use rm, the launch-process deny does fire — Tool execution denied: launch-process — and then the agent says "I can use the remove-files tool instead" and deletes it that way.)
To actually block deletion you must deny every tool that can perform it, e.g. both launch-process and remove-files:
auggie --print --permission "launch-process:deny" --permission "remove-files:deny" \
-i "Delete canary.txt"
# → both blocked, file survives
What did you expect to happen?
Either:
- A way to express intent-level permissions (e.g. a "destructive file operations" category, or a group that covers
launch-process + remove-files + any future deletion path), so denying one obvious tool isn't silently bypassed; and/or
- Documentation that clearly warns: denying
launch-process alone does not prevent file mutation/deletion — list every tool that can mutate the filesystem (remove-files, save-file/str-replace-editor, etc.) so users can deny the full set.
The current behavior is a permission-completeness / discoverability gap: each individual rule works as specified, but the intent ("don't let the agent delete my files") is easy to under-specify and the bypass is silent.
Steps to reproduce
- In any workspace, create a file:
echo hi > canary.txt
- Run:
auggie --print --max-turns 5 --permission "launch-process:deny" -i "Delete the file canary.txt from this workspace."
- Observe: the agent uses
remove-files and canary.txt is deleted, even though launch-process is denied.
Auggie version
0.28.0 (commit 63537d73)
Request ID
N/A (local tool-permission behavior)
Environment details
Environment
- OS: macOS (darwin x64)
- Shell: zsh / bash
- Node: v22.22.3
- Tool/CLI version: auggie 0.28.0 (commit 63537d73)
Anything else we need to know?
Surfaced while verifying #74 (sub-agent permission enforcement — which appears fixed on 0.28.0). This is a separate, orchestrator-level gap: the deletion fallback happens for the main agent too, not just sub-agents. A "deny by capability" model (or at least docs listing all filesystem-mutating tools) would close the footgun.
What happened?
Denying the
launch-processtool viatoolPermissionsdoes not prevent file deletion: the agent transparently falls back to the dedicatedremove-filestool and deletes the file anyway.A security-conscious user who denies
launch-process(the obvious "run any shell command" tool) to block destructive operations likermgets a false sense of safety — there is no single rule, group, or category that blocks "delete a file," and the fallback happens silently.Verified on auggie 0.28.0 (commit 63537d73).
canary.txtis gone, despitelaunch-processbeing denied. (If I instruct it to specifically userm, thelaunch-processdeny does fire —Tool execution denied: launch-process— and then the agent says "I can use theremove-filestool instead" and deletes it that way.)To actually block deletion you must deny every tool that can perform it, e.g. both
launch-processandremove-files:What did you expect to happen?
Either:
launch-process+remove-files+ any future deletion path), so denying one obvious tool isn't silently bypassed; and/orlaunch-processalone does not prevent file mutation/deletion — list every tool that can mutate the filesystem (remove-files,save-file/str-replace-editor, etc.) so users can deny the full set.The current behavior is a permission-completeness / discoverability gap: each individual rule works as specified, but the intent ("don't let the agent delete my files") is easy to under-specify and the bypass is silent.
Steps to reproduce
echo hi > canary.txtauggie --print --max-turns 5 --permission "launch-process:deny" -i "Delete the file canary.txt from this workspace."remove-filesandcanary.txtis deleted, even thoughlaunch-processis denied.Auggie version
0.28.0 (commit 63537d73)
Request ID
N/A (local tool-permission behavior)
Environment details
Environment
Anything else we need to know?
Surfaced while verifying #74 (sub-agent permission enforcement — which appears fixed on 0.28.0). This is a separate, orchestrator-level gap: the deletion fallback happens for the main agent too, not just sub-agents. A "deny by capability" model (or at least docs listing all filesystem-mutating tools) would close the footgun.