Serious Cursor Agent incident: destructive rd /s /q, real data loss, no backend record found, and no human reviewer yet
I want to report a serious Cursor Agent incident on Windows that caused real data loss on my machine.
This was not simply an AI making a bad code edit. Cursor Agent had terminal access and executed a destructive recursive deletion command that appears to have been misparsed.
The deletion scope I authorized was limited to specific project and development-tool directories. I did not authorize deletion of the C: drive root, the entire Desktop, unrelated projects, or personal files. My local evidence preserves those scope limitations.
After an earlier deletion attempt failed because files were locked, Cursor Agent executed:
Get-Process -Name node,esbuild -ErrorAction SilentlyContinue | Stop-Process -Force -ErrorAction SilentlyContinue; Start-Sleep -Seconds 2; cmd /c "rd /s /q \"c:\Users\ASUS\Desktop\ai_demo_pages_v6\tools\upload-tool-desktop\\""
The quoting is problematic because PowerShell does not use \ to escape ". In a non-destructive reproduction, the command can parse with a standalone \ argument, which on the C: drive may refer to the root directory.
More importantly, immediately after execution, Cursor Agent itself stated:
“The delete command may have misparsed the path. Checking project state and stopping any runaway process.”
It then issued an action described as:
“Stop bad delete process; verify project folders”
and forcibly stopped PID 43984.
After this incident, I experienced actual data loss.
The second major problem: Cursor Support keeps saying it cannot find the corresponding backend record
I submitted a complete evidence package to Cursor Support, including the original Agent JSONL, shell commands, deletion-related records, Cursor local logs, and SHA-256 integrity hashes.
However, Cursor’s AI support assistant, Sam, has repeatedly told me that it cannot find any backend log corresponding to the session ID I provided.
Support later suggested that the ID may be a local Composer/session identifier rather than the backend Request ID.
That may explain why this specific ID is not searchable, but it does not resolve the larger issue:
the model was clearly used, the Agent clearly executed terminal commands, and a destructive incident clearly occurred — yet first-line support currently cannot correlate the session to the backend activity.
Sam has also explicitly told me that the AI support channel cannot perform engineering-level correlation using Auth0 IDs, application UUIDs, PID information, provider metadata, or safety telemetry.
The third major problem: I still have not been connected to an actual human reviewer
This is now one of my biggest concerns.
So far, I have only received responses from Sam, Cursor’s AI Support Assistant.
In one ticket, Sam told me that deeper session review and my compensation request required a teammate and that the case had been forwarded.
In another ticket, Sam then said the case would not be escalated to engineering, product safety, security, or incident response, while also acknowledging that the AI support channel itself does not have access to the engineering-level data needed to investigate the incident.
So at this point:
-
Cursor’s AI support says it cannot find the backend record using the ID I have;
-
Cursor’s AI support says it cannot perform the deeper technical correlation needed;
-
and I still have not been put in direct contact with a human engineer, product-safety reviewer, security reviewer, or incident-response person who can actually investigate what happened.
That is the part I find most difficult to understand.
This is a real destructive-Agent incident with real data loss, not a routine billing question or a minor support issue.
What I want Cursor to investigate
I want a real human technical reviewer to answer:
-
Why did Agent generate and execute a potentially misparsed
rd /s /qcommand outside the intended deletion scope? -
Why was such a destructive recursive command not stopped by stronger path validation or confirmation?
-
What did PID
43984actually access or delete before it was stopped? -
Why can Cursor Support not correlate this incident with the backend model activity?
-
Are there request IDs, routing records, usage records, safety telemetry, or other internal records that can reconstruct what happened?
-
Why has a serious data-loss incident still not been assigned to a human engineering / product-safety / incident-response reviewer?
I have also requested compensation because the incident caused real loss, but my main concern is bigger than subscription credit:
When a Cursor Agent executes a destructive local terminal command and causes real data loss, is there actually a human incident-response path capable of investigating it end to end?
If anyone here — especially Cursor staff — can help get this case in front of a real human technical reviewer, I would appreciate it.
I have already preserved and submitted the complete local evidence privately to Cursor Support.
