Cursor executed destructive filesystem operations after a simple cache cleanup request, resulting in massive unintended data loss (~300GB) and partial corruption of my Windows environment.
The request was limited to:
cleaning Expo / Android / build cache
However, the AI escalated this into recursive deletion commands that affected directories outside the project scope, including user-level folders.
This behavior is extremely dangerous and indicates a lack of path validation and execution safeguards.
Steps to Reproduce
1- Open a project using Cursor with terminal execution enabled
2- Ask the AI to:
clean cache (Expo / Android / node_modules)
3- Let the AI automatically generate and execute commands
4- In my case, it attempted to:
-delete node_modules
-clean Android / Gradle / npm caches
5-Due to incorrect quoting / path handling, a command similar to:
rmdir /s /q “target_path”
was executed with an incorrect scope
6-This resulted in recursive deletion affecting unintended directories
Expected Behavior
The AI should:
-strictly limit file operations to the project directory
-validate paths before execution
-prevent recursive deletion outside scoped folders
-require explicit confirmation for destructive commands (rm -rf, rmdir /s /q)
-never escalate a cache cleanup request into system-level deletion
Operating System
Windows 10/11
Version Information
it wiped itself , the version had available composer 2
For AI issues: which model did you use?
Opus 4.7
Additional Information
System experienced:
loss of ~300GB of data
partial deletion of user directory (C:\Users...)
Windows instability (Explorer issues, missing files)
Logs indicate:
unsafe use of rmdir /s /q
potential incorrect quoting / path resolution
mixing PowerShell and CMD execution
This is not an isolated incident; similar reports exist involving unintended deletions.
Hey, sorry about the data loss. What you described (PowerShell + rmdir /s /q with bad quoting, and the path resolving to the drive root) is a known class of bugs on Windows, and we’re tracking it. Similar reports are here:
Root cause: on Windows we don’t have a filesystem sandbox (like seatbelt on macOS or Landlock on Linux). When we generate cmd /c rmdir /s /q "path" from a PowerShell terminal, quotes and \ are interpreted differently by the two shells, and the path can collapse to the drive root. The /q flag suppresses confirmation.
Recovery steps (do this ASAP while it’s still possible):
Don’t write anything to the affected drive, it reduces recovery chances
On NTFS, tools like Recuva, R-Studio, and PhotoRec often help. Run them from another drive or a USB stick
If System Restore or File History or OneDrive was enabled, check those
Shadow copies: run vssadmin list shadows in an admin cmd
To reduce the chance of this happening again right now:
In Cursor Settings, turn off Auto-run for terminal, or set up Command Allowlist or Denylist. You can add rmdir, rd, Remove-Item, del /s to the denylist
Don’t run the agent with access to your user profile or system drives unless you really need to. If possible, keep projects in a separate folder with no sensitive data nearby
If you have the Request ID from that chat (chat context menu > Copy Request ID) or a screenshot or copy of the exact terminal commands, send it here and we’ll add it to the report. When there’s an update on a fix, I’ll reply in the thread.
I understand what you’re saying, but this is honestly unacceptable. I didn’t just lose “some files”, I lost years of work, projects, data, and personal files just because I trusted your tool to do something as simple as cleaning cache. I run multiple businesses and development projects, and a huge part of my workflow and assets were on that machine. We’re talking about hundreds of gigabytes gone in seconds.
I didn’t ask Cursor to touch my system, I didn’t ask it to access my user directory, and I definitely didn’t ask it to execute anything that could affect my entire disk. I gave it a very basic request, and it escalated that into a destructive operation that went completely out of scope.
Saying this is a “known class of bugs” actually makes it worse. If this was already known, then there should have been strict protections in place. At the very least, destructive commands like rmdir /s /q should never run silently, and definitely not without confirming the exact path being affected.
What’s really hard to accept is that there is no sandbox, no enforced limitation, and no safety layer preventing the AI from touching critical parts of the system. This is not just a bug, this is a serious design issue. A tool like this should not be capable of wiping user data from a simple cleanup request.
I trusted Cursor as part of my development workflow, and that trust resulted in massive damage. I’m still trying to recover what I can, but a lot of it is likely gone permanently and still dont know exactly what i lost.
I will send logs and the request ID, but I really expect this to be treated as a critical issue, not just another report.
you did not lose all of your data! it is still on the drive and recoverable so long as you do not write to the drive. I went through a similar process recently of having to recover data and it sucks! but it’s possible. If you’re able to remove the drive from the system for now, do it! this will guarantee nothing else will happen to the data that is still on the drive. I have used TestDisk and a few other tools mentioned above, there are some good github repos with free tools as well. I would suggest putting the drive aside for a few days and let the frustration wear off a bit before you attempt to restore the drive. feel free to chime back in here if you need help and i’m sure some of us can respond with some guidance if needed.
There are two ways ive handled data recovery, the destructive way is more annoying because you will lose all of the names of your files and folders, the non-destructive way will simply “undelete” the data and everything gets restored as is so long as the drive can still read the partition tables and data as it was. if you reformat it or do anything else to damage the records, you’re left with having to rename and organize everything which can take a very long time.
Get an extra backup drive if you dont already have one, spinning drives are pretty cheap now with large data sizes. you can get a 5200rpm instead of 7200 to save, but it will take longer to recover and scan the drive. however, this way you can make a copy of your lost data drive on the new one, then work on the drive to recover the data, if anything goes wrong at least you’ll have a ghost copy to try again.
i used recuva and it recovered 250gb of data but most of them are corrupted i tried to fix them using online tools but unfortunately none of them worked
If you recovered it into a secondary drive and not the damaged drive, are there any possibilities of trying a different app? something else may build out the partition better?
How can I add a rejection list under the “Run Everything” settings as you described? I can’t find it anywhere. The key issue is that your Use Allowlist is terrible. Almost everything requires manual confirmation. Why not learn from Claude’s latest automatic mode? Recursive deletion commands like this are too easy to occur in Windows.
So true. I sympathize with these users, but at the same time what are they thinking.
Everything I am working on is backed up constantly and git commits are made and pushed after any notable amount of work is done, dozens of times throughout the work day.
Same with personal files. I at least back them up on a separate drive throughout the year and upload to the cloud if they are on only one device. It sucks to lose a ton of files, but how are there no backup measures taken.
Also I would not trust any of these ai agents with running commands like rmdir, this is why the allowlist feature exists.
Guys we’re not here for blaming the user. Regardless what the user DID.. The Software still responsible for this.. At least respect your first heading:
Cursor is the best way to code with AI.
and other competitors beat you in these ESSENTIALS..
Cursor is to blame, but if this issue is that widespread, why would anyone use Cursor with such grave risks, and why wouldn’t any sane user just disable the ai agent from running anything but the most innocent commands. At some point you have to blame the user for using the tool that is so obviously broken and dangerous. However, I do think majority of users are not having this issue, which is why Cursor gets away with just brushing it off. I don’t agree with cursor’s response, but its not as widespread as you are making it. And every time I read these stories, they never post the prompt. Most likely, because it would reveal huge negligence on the user’s part.
I personally have a very limited list of commands on my allowlist. Just manually approve the commands each time and make sure it is correct, or sandbox cursor yourself (Virtualbox), at least until Cursor gets their act together with this issue.
I agree with all this. Cursor doesn’t care since this problem could be solved by verifying rmdir and other removal commands before executing them, or some sort of simulation run to verify if it would touch a file outside the project directory. Like swapping “rmdir” with just “dir” and iterating though the files to see if any are outside the project and counting how many files and folders it will delete and possibly the total size of those files. Then if its past some threshold or files outside the project, it pops up a confirmation and the user accepts or not, but at least the user has some useful information. This is such an easy safety feature to implement its just silly.
The more powerful a tool is when matched with someone inexperienced the more likely they are to be burned.
Cursor is to be blamed. But the user is to be blamed too for not knowing what they are doing and what accepting a rmdir command could actually mean. It’s like we need a PSA or warning for anyone using these tools, but stuff is moving so fast. People should be very wary about any ai agents manipulating filesystems.
The easiest thing people could do is create a new windows user called “Cursor” with no admin rights, then run cursor ide as that user (even while logged into your normal user account). Optionally could give that cursor user specific project folder access. This way Cursor should not be able to remove anything that the Cursor user does not have access to. Probably need to install Cursor under that user as well, but still that should work.
It is egregious that this is possible at all. If I wrote a prompt that said delete everything in my program files folder, would it do it without some serious warnings? If so, then that is just bad software.
I dont actually think the user has been prompted to Execute the command, ig he already allowing every command to be executed automatically.. While Cursor is still sleepy to add essential security layers
A quick note to everyone in this thread – the discussion has drifted away from the original topic and some of the recent replies haven’t been constructive. We understand this is a frustrating issue, and that frustration is completely valid. But please keep replies respectful and on-topic so the thread stays useful for anyone experiencing similar problems.
@Seif_Maloufi – if you’re able to share the Request ID from that chat session (chat context menu > Copy Request ID) or the exact terminal commands that were run, that would help us strengthen the report. And if you have any updates on the recovery, feel free to share here.
It’s clearly constructive when we are discussing possible workarounds to prevent this issue and possible solutions cursor devs could implement to prevent this pretty serious issue.
