Cursor deleted both my hard disk and my OneDrive without being asked to, removing important system files too. I asked it to fetch a github repo and make a copy on my OneDrive, but it fetched a wrong repo, so I told it “delete that repo copy and make one with this exact repo” and gave it the link. It proceeded not only to delete the folder it created, but my whole OneDrive and my main hard disk. While I tried recovering my files (cursor was already deleted), it deleted the old versions of my folders that I was recovering, so now they’re lost for good.
Steps to Reproduce
tell it to copy something from online locally in your OneDrive folder, then ask it to delete the copy and copy another thing.
It then
Expected Behavior
it should have deleted only the folder I told it to delete,
Operating System
Windows 10/11
Version Information
IDE:
Version: 3.1.17
VS Code: unable to get since it deleted the program.
Additional Information
I understand it not being in a protected environment, perhaps deleting all my files as well. But the deleting the recovery versions of files is completely over the limit, unacceptable.
Hey, that’s a really rough situation. I’m sorry about the data loss.
We know about this class of bug. On Windows there’s no sandbox isolation, and with certain quote escaping at the PowerShell → cmd.exe boundary, commands like rmdir /s /q can resolve the path to the drive root. The /q flag also suppresses confirmation. There have been a few similar reports in the last few weeks:
Hey @alex-elia, I’m sorry, losing data is awful, especially AppData.
To look into your specific case, we’ll need a bit more info:
Cursor version Settings > About
Was Auto-Run enabled
The Request ID from the session, if you still have it Chat context menu > Copy Request ID
What you asked the agent to do right before it happened
If there’s a lot of session info, it’s better to open a new thread for your case and drop the link here so the report doesn’t get lost in this old thread.
For the future, to reduce the risk of this kind of incident:
Keep the agent’s working folder separate from system directories AppData, OneDrive, Documents, drive root, for example C:\dev\...
Don’t enable Auto-Run for destructive operations, review each command before you approve it
Make regular git commits, plus back up critical data before cleanup or migration tasks
Models are improving over time at following instructions and being more careful with destructive operations, and this is an active area of work.
This is exactly the class of failure where “better model behavior” is not enough.
For destructive operations, I think agent tools need a hard boundary around the working directory, plus a separate confirmation path for anything that deletes, moves, or rewrites files outside that boundary.
A practical rule I’ve started using is:
never run agents from OneDrive, Documents, AppData, or a drive root
keep all agent work inside a dedicated workspace folder
treat delete / cleanup / migration commands as high-risk
require the agent to state the exact resolved path before execution
require a second confirmation if the target path is outside the repo/workspace
log the command and result afterward
The scary part here is not just that the command was wrong. It is that the command was both destructive and quiet. rmdir /s /q plus path escaping bugs is a terrible combination.
For serious agent work, destructive operations need a lifecycle and an audit trail, not just a prompt instruction like “be careful.”