Production Data Loss Incident Caused by Cursor Agent Shell Command

Support Bug Reports
, , , , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

I am posting this as a serious warning to the Cursor team and community after a catastrophic production incident that I have now fully forensically investigated.

On May 13, 2026, while using Cursor in normal Agent workflow mode on a Windows production server, the agent responded to a simple prompt:

“sync”

The agent then generated and executed a recursive Windows deletion command through cmd /c with incorrect quote escaping. According to the forensic evidence recovered from Cursor’s own logs, SQLite state databases, terminal recordings, renderer logs, process-monitor logs, and agent conversation history, the malformed command recursively deleted from the root of C:\ instead of the intended project subfolder.

The result:

  • IIS production environments destroyed
  • deployment folders deleted
  • SSL/private keys broken
  • Chrome/Edge installations damaged
  • SQL/MySQL services impacted
  • ~250GB removed from disk
  • Cursor itself partially deleted and unable to reopen

This was not malware.
Not ransomware.
Not a hardware failure.
Not user error typing rd /s /q C:\.

The evidence shows the command was generated and executed by the Cursor agent itself during a normal repository synchronization workflow.

I now possess:

  • full forensic timelines
  • recovered composer conversations
  • exact tool calls
  • terminal recordings
  • timestamps down to milliseconds
  • the exact destructive command
  • the agent’s own internal reasoning after the event

Most disturbing of all:
after reading terminal output clearly showing deletions under \inetpub\, the agent internally downplayed the event and continued operating instead of halting.

I am requesting:

  1. Immediate formal escalation from Cursor/OpenAI/Anysphere engineering leadership
  2. Serious investigation into unsafe shell-command generation on Windows
  3. Acknowledgment of the incident
  4. Appropriate compensation for the operational damage and recovery work caused
  5. Immediate safety mitigations for all Windows users running Agent mode

If this incident is ignored or minimized, I intend to publicly release a fully transparent technical breakdown of the event, including forensic evidence and reconstructed timelines, so other developers and companies understand the real operational risks of running autonomous AI agents with elevated privileges on production infrastructure.

This is not a threat.
This is responsible disclosure following a production-destructive failure that could happen to other users.

I strongly recommend:

  • NEVER running Cursor Agent as Administrator
  • NEVER granting unrestricted shell access on production systems
  • NEVER auto-approving destructive commands
  • EXTREME caution with Windows cmd /c nested quoting flows

I hope Cursor treats this incident with the seriousness it deserves.

Steps to Reproduce

  1. Run Cursor Agent mode on Windows with elevated/admin privileges.
  2. Work normally inside a Git repository.
  3. Ask the agent to perform a repository synchronization workflow (in this case the prompt was simply: sync).
  4. Agent attempts to resolve a file/folder permission issue.
  5. Agent generates and executes a nested quoted Windows command through:
    cmd /c "rd /s /q \"<path>\""
  6. Due to Windows shell quote parsing/escaping behavior, the path argument becomes corrupted and resolves to drive root (C:\) instead of the intended folder.
  7. rd /s /q recursively deletes large parts of the drive without confirmation.

Observed result:

  • Massive filesystem deletion under C:\
  • IIS failure
  • application corruption
  • browser corruption
  • SSL/private key damage
  • Cursor self-corruption

Expected result:

  • Agent should never execute destructive recursive deletion commands through unsafe nested shell quoting.
  • Agent should validate resolved paths before execution.
  • Agent should halt immediately if terminal output indicates root-level deletion.

Expected Behavior

The agent should safely resolve and validate filesystem paths before executing destructive commands.

Recursive delete operations should:

  • never execute against drive root or ambiguous paths
  • require explicit confirmation and path verification
  • use safe native APIs instead of fragile nested shell quoting
  • automatically halt if output indicates unexpected system-level deletion activity

A simple repository sync request should never be capable of recursively deleting large portions of a production Windows system.

Operating System

Windows 10/11

Version Information

  • Cursor version: 3.2.14
  • OS: Windows Server 2019 Standard
  • Environment: Production IIS + SQL Server server
  • Agent Mode: Enabled
  • User privileges: Administrator
  • Shell environment: PowerShell invoking cmd /c
  • Repository type: Git monorepo
  • Incident date: 2026-05-13

For AI issues: which model did you use?

Composer 2.0 running in Cursor Agent mode.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

Was max mode enabled when this happened? Do you remember the % of context in use?

I once got Composer 2 without max mode deleted a bunch of files it was working with, and that happened when context reached 100%.. It was not a big deal because it was a test server and files were tracked source code, so rollback was easy.

8

Thank you for the detailed and thorough report. I’m sorry about the damage this caused to your production environment. We take these reports seriously.

To help us investigate your specific incident, could you share:

  1. Request ID from the failing conversation (three dots menu at the top right of the chat > Copy Request ID). How to find your Request ID

  2. The exact destructive command that was executed (you mentioned recovering it from forensic evidence)

  3. Your auto-run setting at the time of the incident — were terminal commands set to auto-run, or did you have manual approval configured? (Cursor Settings > Agents > Auto-run)

In the meantime, the safest mitigations (as you’ve already identified) are:

  • Do not run Cursor as Administrator on production systems

  • Disable auto-run for terminal commands or use the Command Allowlist to require manual approval for destructive commands

  • Use User Rules to add safety constraints for your environment

Our engineering team is aware of this class of issue and actively working on improved safety guardrails for agent terminal commands. Regarding your request for compensation, please mail [email protected] as they’re better equipped to handle these requests.