[Agent] Autonomous `rd /s /q` wiped the entire D: drive (Windows)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Agent, running in autonomous (Agent) mode, executed a Windows cmd command intended to delete a single deprecated project directory. Because cmd.exe mis-parsed the escaped-quote sequence, the rd /s /q command was applied to the D:\ drive ROOT instead of the target subdirectory, recursively deleting the entire D: drive.

This permanently destroyed (no Recycle Bin):

  • WeChat chat history database
  • multiple source-code projects
  • installed applications

Steps to Reproduce

  1. Run Cursor Agent on a Windows project located on a non-system drive (e.g. D:).
  2. Ask the Agent to delete a directory whose path contains non-ASCII (Chinese) characters and nested backslashes.
  3. The Agent wraps the path like: cmd /c “rd /s /q "d:<project>\src\views...\vehicleTrack_GL"”
  4. Windows cmd truncates the path at the escaped quote, so rd /s /q runs against D:\ and recursively deletes the drive.

Expected Behavior

  • Only the intended subdirectory should be deleted.
  • Irreversible, non-Recycle-Bin commands such as rd /s /q (recursive delete) should trigger an explicit confirmation gate, or be blocked entirely, before the Agent executes them.

Operating System

Windows 10/11

Version Information

Cursor IDE, Windows desktop, Agent mode

For AI issues: which model did you use?

Agent mode — mixed (gemini-3.8-flash-high, composer-2.5-fast, etc.)

For AI issues: add Request ID with privacy disabled

Session a7cf2b75-380b-4262-9485-547cc415dbda / terminal 672262

Additional Information

The Agent later self-admitted in the session transcript: “Windows cmd does not parse the escaped quote as expected, causing the command to actually recursively scan and delete the D:\ root directory instead of the target subdirectory. Logs show it ran for ~105 seconds.”

Local evidence available (can provide privately on request):

  • Session transcript ID: a7cf2b75-380b-4262-9485-547cc415dbda
  • Terminal task log: 672262
  • Exact command: cmd /c “rd /s /q "d:...\vehicleTrack_GL"”

Happy to share the full logs and transcript privately (via email) — I intentionally did not attach them here because they contain personal account paths.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @luck_li, thanks for the report, and I’m really sorry about the data you lost on D:.

You don’t need to post the logs publicly. Using the session ID you shared, we found the run and can see the command that caused this. What you described matches an issue we’re already tracking, and I’ve added your report to it. In PowerShell, a backslash does not escape a quote the way it looks in that command, so rd /s /q received the root of the current drive (D:) as an extra target alongside the folder you wanted removed.

If you haven’t already: avoid writing anything new to D: and run a recovery tool (for example Recuva, PhotoRec or TestDisk) from another drive, restoring to another drive. Deleted data stays recoverable until it is overwritten, and on an SSD the chances drop quickly.

Two questions that would help the team:

  1. Which run mode was the Agent using at the time? You can see it in Cursor Settings > Agents > Approvals & Execution (Ask Every Time, Allowlist, Auto-Review or Run Everything).
  2. Did an approval prompt appear for that delete command, or did it run on its own?

To protect against this going forward on Windows, set the run mode to Ask Every Time (or Allowlist with an empty list) so every terminal command waits for your confirmation. Terminal commands on Windows don’t run in a sandbox, so your confirmation is the main safeguard. Note that File-Deletion Protection applies to the Agent’s own file-delete action, not to terminal commands like rd or rmdir.