Cursor AI Agent tried to delete one ComfyUI custom-node folder but mis-executed rmdir /s /q on Windows due to broken quoting. It attempted recursive deletion from D:\ root. ComfyUI install + games/other files lost. rmdir /s /q bypasses Recycle Bin. Posting for awareness — please review agent shell commands manually before approving destructive ops.
Hey, thanks for sharing this and posting it. I’m really sorry, data loss always hurts, especially when it hits both work files and personal stuff.
The scenario itself is familiar. On Windows, with certain quoting between PowerShell and cmd.exe, a path passed into rmdir /s /q can collapse to the drive root, and the command will recursively delete way more than intended. rmdir /s /q also bypasses the Recycle Bin, so you can’t just restore it from there.
What to do right now for recovery:
Stop writing anything to that drive D: The fewer writes, the better the chance of recovery.
Run a file recovery tool like Recuva, PhotoRec, or similar on drive D: as soon as you can.
Check backups, File History, and any cloud sync you had set up.
How to prevent this from happening again:
In Settings → Agents → Auto-Run, set shell commands to Ask Every Time, not Run Everything and not a broad allowlist, and enable File-Deletion Protection and External-File Protection. This won’t fix quoting itself, but it blocks silent auto-run paths so you can catch a destructive command before it runs.
Run risky or destructive operations on a separate disk, in a VM, or in a container, and keep git plus regular backups.
I can’t give a specific timeline for a fix. If you can, send the exact command the agent ran and the conversationId for that chat. That’ll help as a forensic datapoint.
The quoting-collapse you found is the nasty part, the command looks fine until the path resolves to D:\ root, and by then it’s gone. “Review before approving” only catches it if you expand the glob in your head exactly like cmd.exe does, which nobody does mid-task.
What I’ve been building treats rmdir /s /q (and the PowerShell Remove-Item -Recurse -Force variant) as non-recoverable by definition, it bypasses the Recycle Bin, so there’s nothing to restore, and hard-stops it before it runs, no matter how the path is quoted. Recoverable stuff gets snapshotted first for a one-command undo.
Hey, good point. You nailed it: “review before approving” doesn’t catch this case well, because path collapse isn’t visible at a glance. The command looks fine right up until the path resolves to the drive root.
Framing “recursive delete is non-recoverable by definition” is the right call. Cursor already has File-Deletion Protection and External-File Protection in Settings → Agents → Auto-Run, which stop silent auto-run for destructive actions, but they don’t cover every quoting variant yet. Strengthening safety around destructive shell commands is something we’re working on, but I don’t have a specific ETA.
About your tool: we can’t officially integrate or endorse third-party solutions, but if you want to share your approach or a link in the thread, the community will likely find it useful. We won’t block it.
It’s a pre-execution hook: it snapshots the target before a destructive command runs so you get a one-command undo, and it hard-stops the class it can’t recover (a root-level rmdir /s /q, force-pushes, infra destroys) instead of pretending it captured something. Default mode is shadow, observe-only, it just logs what it would have done, so you can watch it on a low-stakes project before trusting it with anything real.
Today the auto-fire hook is Claude Code; a Cursor adapter via the hooks API is next, and the CLI check works anywhere in the meantime. It’s a beta, if you run it and it makes a wrong call on a real command, that report is the most useful thing you can send me.
Cuckoo_guo, hope the recovery went as well as it could.
Thanks for getting it into a working state and sharing it. The pre-execution snapshot approach and a hard stop for clearly non-recoverable actions (rmdir /s /q, force-push, infra destroy) make sense, mainly because you can’t easily see the path to failure until you actually run it.
A couple of notes for anyone who finds this thread later. This is a third-party beta tool, we haven’t officially reviewed it, and we can’t guarantee or endorse it. The advice is solid though. Try it in shadow mode observe-only on a low-risk project first before trusting it with real commands.
On the Cursor side, the best practical safety barrier right now is Settings → Agents → Auto-Run. Set shell commands to Ask Every Time, not Run Everything and not a broad allowlist, and keep File-Deletion Protection and External-File Protection enabled.