While working in Agent mode on a Next.js project, I asked the agent to revert a recent change by removing a subfolder (tools/conedison). Instead of only deleting that folder, the agent used Windows recursive delete commands (Remove-Item -Recurse -Force and rmdir /s /q) with incorrect path quoting. The command did not stay scoped to the project. Large portions of my Windows user profile under C:\Users<username> were deleted, including Desktop, Documents, Downloads, my git repo, and most project files. rmdir /s /q bypasses the Recycle Bin.
Environment
OS: Windows 10/11
Cursor: Agent mode with shell/terminal access
Task: Remove tools/conedison inside a repo; keep other work
Steps to Reproduce
Steps to reproduce (approximate)
Open a project in Cursor Agent on Windows.
Ask the agent to delete a subdirectory (e.g. revert a prior step by removing tools/conedison).
Agent attempts Remove-Item -Recurse -Force on the folder; if that fails (file in use), agent runs cmd /c rmdir /s /q with a quoted path containing spaces.
Due to malformed quoting / wrong target, recursive delete runs against broader paths than intended.
Expected Behavior
Expected behavior
Only the requested project subfolder is removed.
No recursive delete on paths outside the workspace without explicit user confirmation.
Destructive commands like rmdir /s /q and Remove-Item -Recurse -Force on user profile or drive roots are blocked or require approval.
Operating System
Windows 10/11
Version Information
Actual behavior
Most of C:\Users<username> was deleted (Desktop, Documents, Downloads, project tree, .git, etc.).
Only fragments remained (e.g. AppData, .cursor, partial eyn, empty OneDrive\Pictures).
OneDrive cloud recycle bin and System Restore did not restore the lost data.
I’m aware that I should have been more careful and that I should create better gauardrails myself. But to be clear, this is something that can be prevented by better system prompting and better guardrails from cursor. Needless to say I’m never using cursor again.
Hey, this is a really stressful situation. Losing data outside the project hurts, especially when OneDrive and System Restore didn’t help. Thanks for taking the time to document the steps, it helps.
Here are a few more things you can try for recovery. rmdir /s /q marks space as free, but it doesn’t overwrite it right away, so the less disk activity, the better your chances.
Stop writing anything to C: including installs and extra reboots. If you can, work from another drive and connect the affected disk as a secondary drive.
Try file recovery tools like Recuva, PhotoRec, R-Studio, or EaseUS Data Recovery. Run them from another drive or a USB.
Check Windows File History: Settings > Update & Security > Backup. If you enabled it before, a backup might be there.
Check Previous Versions: right click the parent folder > Properties > Previous Versions. Something might still be in Volume Shadow Copy.
If the data is critical, consider a professional data recovery service, as long as the disk hasn’t been heavily used.
On the Cursor side, models are iteratively learning to handle destructive commands more carefully, and the team is working on improving safety behavior in this area. But I can’t give a clear ETA for specific Windows shell protections.
A few habits that really reduce risk in the future, with any AI tool, not just Cursor:
Don’t auto run shell commands in Agent mode. Turn off auto approve at least for commands like rm, rmdir, Remove-Item, Format-, and read each command before you approve it.
Commit to git often, even WIP, and push to a remote. It can save your project.
Back up important folders outside C:\Users\<username> like to an external drive or a cloud service with versioning.
For unfamiliar tasks, use Plan mode so you can review steps separately before anything runs.
Appreciate the help. Hope this can be used as an example for better safety features.
No doubt it was on me. But cursor shouldn’t ship with no restrictions on commands by default. You should really make it hard for users to allow the llm to run any destructive commmand
This is valid feedback, and I’ll pass it along. Safer defaults for destructive shell commands on Windows is exactly what the team is working on, both on the model side, so it interprets intent more carefully and doesn’t escalate to /s /q flags unless it’s clearly needed, and on the harness side, with auto run guardrails and command level review. I can’t share an ETA for specific protections, but a report with this level of detail really helps with prioritization.
If you decide to give Cursor another try later, on Windows it’s worth going to Settings and turning off auto run for shell, or at least adding rm, rmdir, Remove-Item, Format-, del /s to the deny list. Plan mode for destructive tasks also helps reduce risk.
Let me know if any of the recovery steps help you get the data back.
Funny enough I’m still using it. I tried codex, and copilot on VS but they are not as good. I still want an IDE but other options out there are not as good or easy to use.
I just need to be more careful on commands and now I run it inside a separate environment.
Glad you saw it through and found a setup that works for you. Running potentially destructive tasks in a separate environment is a great habit, and it cuts a huge chunk of the risk.
Thanks again for the detailed write-up. Reports like this directly shape how we prioritize safer default settings. If any of the recovery steps end up working, I’d be interested to hear about it.