Agent permanently deleted entire production resource folder — seeking acknowledgment and support

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hello Cursor team,

I am writing to report a serious incident caused by the Cursor Agent (Auto) during a coding session.

What I asked for
I only asked the agent to create a new RedM resource named ND_Mouthaccessories, based on an existing mouth_accessories script, and to research patterns from nearby resources such as ND_Pets.

What the agent did
While setting up folders, the agent mishandled Windows paths containing square brackets ([ND]). It created an incorrect path, then ran a destructive cleanup command (rmdir /s /q) that targeted the real production folder:

D:\MJ-RedM-BaseRP-18k\MJ-RedM-BaseRP-18k\MJDevCore\resources[ND]

That folder contained my live server scripts (many ND_* resources, including critical systems). After the command, almost everything inside [ND] was gone. Only the newly created ND_Mouthaccessories remained. The deletion was permanent (rmdir /s /q), so the files did not go to the Recycle Bin.

Impact

Loss of current/live project files (not an old backup)
Significant development and server downtime
High risk of permanent data loss if disk recovery fails
What I need from Cursor

Acknowledgment that an agent should never run destructive filesystem commands like recursive delete on project folders without explicit user confirmation
Guidance on escalation / incident handling for agent-caused data loss
Any available support options regarding this damage (recovery guidance, account/support escalation, or compensation policy if applicable)
I did not request deletion of any existing resources. This was an agent operational failure on path handling and unsafe cleanup.

Please advise on the next steps as soon as possible.

Thank you,
wendigo
[email protected]

[email protected]

Date of incident: August 10, 2026
Workspace path: …\resources[ND]\mouth_accessories
Affected path: …\resources[ND] (entire folder contents deleted)

Steps to Reproduce

While setting up folders, the agent mishandled Windows paths containing square brackets ([ND]). It created an incorrect path, then ran a destructive cleanup command (rmdir /s /q) that targeted the real production folder:

D:\MJ-RedM-BaseRP-18k\MJ-RedM-BaseRP-18k\MJDevCore\resources[ND]

That folder contained my live server scripts (many ND_* resources, including critical systems). After the command, almost everything inside [ND] was gone. Only the newly created ND_Mouthaccessories remained. The deletion was permanent (rmdir /s /q), so the files did not go to the Recycle Bin.

Operating System

Windows 10/11

Version Information

Version: 3.4.20 (system setup)
VSCode Version: 1.105.1
Commit: 0cf8b06883f54e26bb4f0fb8647c9500ccb43310
Date: 2026-05-15T02:26:10.351Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

auto

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report. Losing live files really hurts, especially on a work server, so I’ll start with recovery, then how to avoid this going forward.

About what happened

When auto-run is on, the Agent runs terminal commands without asking for confirmation each time. Commands like rmdir /s /q delete files directly, skipping the Recycle Bin, and also skipping Cursor checkpoints and local history (those only cover edits made through the agent’s edit tools, not deletions done in the terminal). So Cursor doesn’t have a local copy of that data.

Recovery, act fast

  1. Stop writing anything to the D: drive right now. Every new write lowers the chance of recovery.
  2. Run a recovery tool like Windows File Recovery from Microsoft, or something like Recuva. For critical data, use a professional data recovery service.
  3. Check git remotes (if the folder was under version control) and any backups or cloud syncs.

To prevent this next time

  • You’re on version 3.4.20, which is about three months old. Update to the latest stable.
  • Switch run mode to Ask-every-time or Allowlist instead of auto-run for destructive operations, so these commands require explicit confirmation. More details on run modes: Run Modes | Cursor Docs
  • Keep production data under version control with regular commits and separate backups.

On your request about acknowledgment, what you described isn’t the behavior we want from the agent. The models and the safety logic around destructive commands are being improved over time, and the team is actively working on it. I’ve shared your case with the team as an extra signal.

For support or compensation questions, please email our team at [email protected]. They can review your specific situation.

Let me know how the recovery goes.