Hey, this is a really serious situation.
Here’s what most likely happened: you were on version 2.4.35 (Feb 10), and that release had a critical encoding bug in terminal scripts. The Russian Windows locale uses code page 1251 (not UTF-8), and that’s one of the triggers for this bug. When running commands through PowerShell, paths could get mangled, and a delete could hit the whole drive instead of a specific folder. This was fixed in later versions.
Also, the File-Deletion Protection and External-File Protection settings only protect against deletions done through Cursor’s built-in tools (the editor and file manager). Terminal commands like rmdir /s /q or Remove-Item -Recurse -Force run directly in the shell and bypass those protections. The team is aware, and we’ve seen a few similar reports:
What to do right now:
- File recovery: run Recuva or R-Studio as soon as possible. Most important, don’t write anything new to that SSD, so you don’t overwrite deleted data. The sooner you start, the better your chances.
- Update Cursor to the latest version. This should close the encoding bug.
- Cursor Settings > Agents > turn off “Auto-run mode”. The agent will ask for confirmation before each terminal command, and you can reject destructive commands before they run.
A few questions for incident tracking:
- Was Auto-run mode enabled?
- Can you share the Request ID from that chat? (Top right of the chat → Copy Request ID)
Let me know if you need help with anything else.