[Bug]: Denying `launch-process` doesn't block file deletion — agent silently falls back to `remove-files`

[harjothkhara]

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:

1. 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
2. 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

1. In any workspace, create a file: echo hi > canary.txt
2. Run: auggie --print --max-turns 5 --permission "launch-process:deny" -i "Delete the file canary.txt from this workspace."
3. 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.