Agent shell execution ran rm -rf after a failed && chain (; semantics) - no dry-run or guard, caused real data loss

[LangLang03]

What happened

While running a move command through the agent's Bash tool, the model issued:

mv cpp/build/model_a cpp/build/model_b . && ls && echo ... && for x in cpp/*; do mv "$x" .; done; rm -rf cpp/build cpp && ls

The first mv failed (one source path was wrong — the file lived elsewhere), so the whole && chain was skipped. But the ;-separated rm -rf cpp/build cpp still executed unconditionally, deleting the entire project source tree plus ~1.8 GB of training data in a single command. The attached screenshot shows the exact command and the aftermath.

The harness executes agent shell commands verbatim via bash -c with no simulation/parsing and no guard on destructive operations. One ; vs && mistake — by the model or by the human reviewing the command — turns a routine directory migration into permanent data loss.

Suggested safeguards

1. Dry-run / simulation before execution: parse the command and report what it would touch (files and directories), especially for rm -rf, mv overwrites, > redirects, dd, mkfs.
2. Destructive-command guard: refuse or require explicit confirmation for commands containing rm -rf / rm -fr / overwriting mv — at minimum when they target the session workspace.
3. Recycle instead of permanent delete: intercept rm (or snapshot the workspace before each run) so deletions stay recoverable.
4. Shell-semantics awareness: flag ; following a failing && chain, or surface exit codes so a partially failed chain is obvious before the destructive tail runs.
5. Workspace snapshots: a cheap git-style snapshot before any Bash run would have made this incident recoverable in seconds.

Impact in our case

• 19 source files, tests, tools, UI and a 1.8 GB dataset deleted irrecoverably from the disk (ext4 with orphan_file — no inode-based recovery was possible).
• Only the files moved out before the failing command survived.
• The source tree was eventually restored because an independent copy existed elsewhere.

Happy to provide more detail. Thanks for considering!

[LangLang03]

[weijiafu14]

这类“一个 ; 让后半段 rm -rf 无条件执行”的事故，现阶段可以先在 DSH 工具执行前加一道独立模型审批，而不是只靠人眼看整条 shell：

dsh plugin --profile web add pi2dsh@0.11.0
dsh plugin --profile web add pi-approval-guardian

可以直接复用 DSH 已配置的 reviewer 模型，例如启动前设置：

export PI_APPROVAL_GUARDIAN_MODEL=deepseek-official/deepseek-v4-flash
export PI_APPROVAL_GUARDIAN_POLICY='拒绝递归删除、不可恢复删除，以及失败链之后仍会无条件执行的破坏性命令。'
dsh web

pi-approval-guardian 默认把每条 bash.command 送给隔离 reviewer。只有 reviewer 返回有效 allow 才进入 DSH 工具执行；deny、超时、模型错误或无效结果都会 fail closed。它审查的是整条 planned command，因此原帖中的：

... && ...; rm -rf cpp/build cpp && ...

会在真正调用 shell 前被看到，而不是等前半段失败以后再补救；通过后的 tool input 还会被锁定，避免“审的是 A、执行成 B”。

这条链路我们在真实 DSH runtime 里验证过 allow 和 deny 两侧：普通命令放行，危险的 sudo rm -rf 被 reviewer 拒绝。pi2dsh 只是把 Pi 的审查插件映射到 DSH 原生 tools/pre-execute，插件原包不需要修改。项目与验证面在 pi2dsh，Guardian 规则说明在 npm。