The Agent was asked to delete files from this session, but it recursively wiped the entire D: drive with rmdir /s /q. About 80GB of data was permanently deleted and did not go to the Recycle Bin. Almost all projects under the workspace d:\cursor\cursorgzq were lost. Cursor’s own rg.exe was also deleted.
Steps to Reproduce
In a Cursor Agent chat, ask the Agent to build an Electron desktop wrapper for a website.
Later ask the Agent to delete the files downloaded in this session (the desktop app and the Electron download in the project folder).
Deletion fails because the .exe is still running and files are locked.
The Agent then runs rmdir /s /q via PowerShell wrapping cmd. The path quoting is wrong, so the delete target becomes the whole D:\ drive instead of the intended folder.
Folders that were in use by running programs survive. Unlocked folders are deleted immediately and do not appear in the Recycle Bin.
Expected Behavior
The Agent should delete only the files the user asked for. If a delete fails, it must not widen the scope to the entire disk. Destructive commands should stay on a verified path, or stop and ask the user, instead of falling back to a more dangerous whole-drive delete.
Operating System
Windows 10/11
Version Information
Cursor IDE
Version: 3.17.21
For AI issues: which model did you use?
Cursor Grok 4.6
For AI issues: add Request ID with privacy disabled
56e6811f-2a60-4c88-b4cf-9f1b231adfe6
Additional Information
The deletion bypassed the Recycle Bin. Folders still in use by running apps survived (e.g. Steam, Huorong, Baidu Netdisk). Unlocked folders at the root of D: were removed, including the workspace plugin projects. Please review the Agent terminal command log for this conversation. Use the Request ID copied from this chat (… → Copy Request ID), not the sample ID in the form template.
Hey, thanks for the detailed report and for including the Request ID. Losing 80 GB really hurts, I’m sorry.
First, about recovery while it’s still possible:
Stop writing anything to drive D: right away. Don’t install apps there, don’t save files there, and if you can, don’t use it at all. rmdir /s /q removes entries from the file table, but the data blocks are often still on disk until they get overwritten.
Try recovery tools from a different drive: Recuva, PhotoRec, or TestDisk. The less you write to D: after deletion, the better your chances of getting the data back.
Check if you have copies in cloud sync, git history, or backups.
About the behavior itself: what you described sounds like incorrect quoting in the PowerShell → cmd chain, which collapses the path to the drive root. That’s a bug we’re tracking, and it’s not something specific to your setup. I can’t share an exact timeline, but I linked your report to the issue we already have.
To help prevent this next time, a couple of practical tips:
Don’t allow auto run for destructive commands. Keep terminal command review on, and always double check rmdirrmdel before confirming.
Keep regular backups and use version control for important projects.
One quick question: did rmdir /s /q run automatically, or did you confirm it? That’ll help the team understand the exact scenario.
The intent is that Cursor scopes its commands to the directory you start it in, so the worst it can do along these lines is nuke a single project.
In CLI-based workflows, it is common to cd into the project directory and type cursor to pin it to that as its root. You then have to explicitly go out of your way to make Cursor see anything else, as with prompts like, “Add feature Foo to the client in terms of ../server API POST /api/foo…”
When you double-click an icon instead, it initially opens wherever the OS tells it to. You then have to say “File | Open Folder” to pin it to a different workspace root, limiting the blast radius of commands the agent runs.
It would not surprise me at all that installing Cursor on a fresh Windows dev box under D: and double-clicking it causes it to see all of D: to start, in the Explorer bar on the left. Such is the nature of Windows, owing to its DOS heritage.
Thanks for clarifying. The fact that the command ran automatically helps explain what happened. I want to stress this again: it wasn’t related to your setup, and you didn’t do anything wrong.
To prevent this from happening again, two things give the strongest protection:
Switch the Agent terminal command run mode to Ask Every Time so every command needs your confirmation before it runs.
Turn on file deletion protection in the Agent settings.
One more helpful detail that @Warren_Young mentioned above: Cursor limits commands to the folder it’s opened in by default. If you launch it from your project folder cd into the project, then run cursor ., or open the folder via File > Open Folder so it’s tied to a specific workspace root, the Agent’s scope is limited to that project instead of the whole disk.
For recovery, same as I said earlier: don’t write anything new to drive D:. The fewer writes after the deletion, the better the chances to recover data with Recuva, PhotoRec, or TestDisk. I can’t give an exact timeline for a fix, but I’ll post an update if I hear anything.
