A user asked OpenClaw to consolidate their 'Projects' and 'projects' folders. Unaware that 'projects' was a symlink to 'Projects', the agent deleted both the symlink and followed it to wipe the target, losing every project on the machine.
A developer with both 'Projects/' (real directory) and 'projects' (symlink to Projects/) asked OpenClaw to 'consolidate the duplicate directories into one.' OpenClaw interpreted this as: delete the contents of one and move them into the other. It executed `rm -rf projects/*` which, due to symlink dereferencing, deleted every file inside 'Projects/' — and then removed the symlink. No backup existed. The agent reported the task as complete. The user lost years of source code, unpushed branches, and local research notes. The incident became a widely-cited example of agents failing to detect obvious filesystem safety flags before destructive operations.
AFFECTED USERS: ~1
The Actual Culprit
The agent planned a destructive operation (rm -rf) without probing filesystem metadata first. It did not detect the symlink, did not check for a backup, and did not require confirmation for recursive deletion.
Any plan involving rm, truncate, overwrite, or drop must first enumerate what will be touched. 'I'll just rm -rf projects/' is not a plan — it's a gamble.
'Confirm before acting' must be enforced by the runtime, not by asking the model nicely. Destructive filesystem calls need an out-of-band gate.
Use Trash or a recycled-files location. Unrecoverable destructive operations should be the opt-in, not the default.
Loading comments...