Skip to main content
NOPE
Medium reported severity

Forum report: Cursor agent delete command mis-parsed by Windows cmd wiped a user's entire D: drive (chat history, projects); Cursor staff say they found the run

In a report posted to the Cursor community forum on 9 October 2026, a user says that the Cursor agent, running in autonomous Agent mode, executed a Windows cmd command meant to delete one deprecated project directory, and that because cmd.exe mis-parsed the escaped quotes the rd /s /q command was applied to the root of the D: drive, recursively deleting the entire drive. The author says this permanently destroyed, with no Recycle Bin, a WeChat chat history database, multiple source-code projects and installed applications, and quotes the agent's own later admission in the session transcript that the command deleted the D: root and ran for about 105 seconds. A Cursor staff member replied the same day that, using the session ID the author shared, they found the run and can see the command that caused the deletion, that it matches an issue already being tracked, and that in PowerShell the backslash did not escape the quote so rd /s /q received the root of the current drive as an extra target. The event date is not stated and the extent of recovery is unknown.

AI system
Cursor coding agent
Occurred
Event date unknown
Reported
9 October 2026
Event location
Unknown
What the AI did
Acted on the person’s behalf
Reported harm
Property LossOther Material Harm
Whose AI use
Their own AI use
Setting
Everyday life · Work
Evidence
AI involvement reported · Causal attribution alleged · 2 sources
4 claims: 1 documented, 1 corroborated, 2 reported. 5 open questions
People reported harmed
1 person

AI system as recorded: The Cursor coding agent in autonomous Agent mode on a Windows machine, using a mix of models the author lists as gemini-3.8-flash-high and composer-2.5-fast; it issued a cmd /c rd /s /q command for a project subdirectory whose path contained non-ASCII characters and nested backslashes

What Happened

The report. The author writes that the "Cursor Agent, running in autonomous (Agent) mode, executed a Windows cmd command intended to delete a single deprecated project directory." According to the author, "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."

Reported loss. The author says this "permanently destroyed (no Recycle Bin)" a WeChat chat history database, multiple source-code projects and installed applications.

The command and the agent's admission. The author describes the agent wrapping a path containing non-ASCII characters in a cmd /c string with escaped quotes, so that "Windows cmd truncates the path at the escaped quote, so rd /s /q runs against D:\ and recursively deletes the drive." The author quotes the agent's later statement 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." The author offers the full transcript and terminal log privately and says they were withheld because they contain personal account paths.

Cursor's reply. A staff member answered on the same day: "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." The reply explains: "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." It recommends recovery tools, asks which run mode (Ask Every Time, Allowlist, Auto-Review or Run Everything) was active and whether an approval prompt appeared, and notes that terminal commands on Windows do not run in a sandbox and that File-Deletion Protection does not cover terminal commands such as rd.

Limits. The event date is not stated. The loss itself rests on the author's account; Cursor's reply confirms the run and the command but does not describe what was deleted. Whether an approval prompt appeared, which run mode was active and how much data was recovered are unknown.

Reported harm

The author reports that a Cursor agent delete command, mis-parsed by Windows cmd, recursively deleted their entire D: drive, permanently destroying a chat history database, multiple source-code projects and installed applications; Cursor staff say they found the run and the command and that the drive root was received as an extra delete target (first-person forum report with a vendor reply).

Outcome

Ongoing

The author says the deletion was permanent (no Recycle Bin). The Cursor staff reply recommends stopping writes to D: and running a recovery tool from another drive, and asks which run mode was active and whether an approval prompt appeared. As read on 10 October 2026 the author had not yet answered those questions, and the extent of any recovery is unknown.

What remains unknown

  • When the deletion happened.
  • Which run mode was active and whether an approval prompt appeared for the command.
  • How much of the deleted data was recovered.
  • Where the author lives.
  • What the issue Cursor says it is already tracking covers.

What the evidence supports

AI involvement: reported. The report states what the agent did: in autonomous Agent mode it executed a cmd /c rd /s /q command meant for one project subdirectory, which the author says cmd.exe mis-parsed so that the command ran against the D: drive root for about 105 seconds, and the author quotes the agent's own transcript admission to that effect. A Cursor staff reply in the thread says the company found the run from the session ID, can see the command that caused the deletion, and explains that the quote was not escaped so rd /s /q received the drive root as an extra target. The report connects the command to the permanent loss of the author's chat history database, projects and applications; the loss itself is described only by the author.

4 claims: 1 documented, 1 corroborated, 2 reported. What the statuses mean

Reported The author says that the Cursor agent, running in autonomous Agent mode, executed a command that recursively deleted their entire D: drive and permanently destroyed, with no Recycle Bin, a WeChat chat history database, multiple source-code projects and installed applications.

Causal attribution. The author attributes the loss to the agent's command; the extent of the loss is described only by the author.

  • forum.cursor.com(opens in new tab) supports · English
    'Cursor Agent, running in autonomous (Agent) mode'; 'recursively deleting the entire D: drive'; 'This permanently destroyed (no Recycle Bin)'; 'WeChat chat history database'; 'multiple source-code projects'; 'installed applications'
Corroborated The Cursor agent executed a cmd /c rd /s /q command intended to delete a single project subdirectory, and because the quote in the command was not parsed as intended the command was applied to the root of the D: drive.

Causal attribution. The author's report and the agent's quoted transcript describe the command; Cursor's staff reply independently confirms the run and the command from the session record. The two accounts differ on the parsing detail (truncation at the quote versus the root added as an extra target).

  • forum.cursor.com(opens in new tab) supports · English
    'Cursor Agent, running in autonomous (Agent) mode, executed a Windows cmd command intended to delete a single deprecated project directory'; 'the rd /s /q command was applied to the D:\ drive ROOT instead of the target subdirectory'
  • forum.cursor.com(opens in new tab) supports · English
    'Using the session ID you shared, we found the run and can see the command that caused this'; 'rd /s /q received the root of the current drive (D:) as an extra target alongside the folder you wanted removed'
Reported The author says the agent later stated in the session transcript that Windows cmd did not parse the escaped quote as expected, that the command recursively deleted the D: root instead of the target subdirectory, and that logs show it ran for about 105 seconds.

Causal attribution. Quoted by the author from a transcript not shared publicly.

Documented A Cursor staff member replied that the report matches an issue the company is already tracking, recommended recovery tools, and asked which run mode was active and whether an approval prompt appeared for the delete command.

Causal attribution. Directly established by the staff reply itself.

  • forum.cursor.com(opens in new tab) supports · English
    'What you described matches an issue we’re already tracking, and I’ve added your report to it'; 'run a recovery tool (for example Recuva, PhotoRec or TestDisk) from another drive'; 'Which run mode was the Agent using at the time?'; 'Did an approval prompt appear for that delete command, or did it run on its own?'

Sources

2 sources inspected. Sources that repeat one account do not corroborate each other.

How the sources were read, and where the events happened

Read in English on 2026-10-10 through the forum's JSON endpoint (opening post and the staff reply). No translation was needed; the research agent (an AI) read the text directly. The author's handle is not recorded. Applies to s1.

Staff reply (marked staff and admin by the forum) in the same thread, read in English on 2026-10-10 through the forum's JSON endpoint; no translation was needed. The research agent (an AI) read the text directly. Applies to s2.

Event countries: Unknown. Affected-person countries: Unknown. Court countries: Unknown.

Neither post says where the author is; no country is inferred from the language of the deleted path or the forum.

Reviewed for publication 2026-10-10: Published under the charter's public first-person rule as a concrete account of an AI coding agent's delete command destroying a user's whole data drive, with the loss attributed to the author's forum report and the command and its cause confirmed in a Cursor staff reply read in the same thread. The author's handle is not recorded.

People described

The forum report's author, a Cursor user on Windows whose projects were on a non-system D: drive

People reported harmed in this case

1 person

1 AI participant · 0 other people harmed

One person: the author of the forum report. Exact 1.

Counted once within this case. The same person may appear in other cases. This count does not establish AI causation.

Tags

#first-person#forum-post#cursor#ai-agent#coding-agent#data-loss#file-deletion#windows

Cite this case

Compiled per our published methodology: verification statuses, sourcing standards, and corrections process.

APA

NOPE. (2026). Forum report: Cursor agent delete command mis-parsed by Windows cmd wiped a user's entire D: drive (chat history, projects); Cursor staff say they found the run. AI incidents. https://nope.net/incidents/2026-cursor-agent-delete-command-quote-parsing-wiped-windows-d-drive-chat-history-projects-first-person-forum

BibTeX

@misc{2026_cursor_agent_delete_command_quote_parsing_wiped_windows_d_drive_chat_history_projects_first_person_forum,
  title = {Forum report: Cursor agent delete command mis-parsed by Windows cmd wiped a user's entire D: drive (chat history, projects); Cursor staff say they found the run},
  author = {NOPE},
  year = {2026},
  howpublished = {AI incidents},
  url = {https://nope.net/incidents/2026-cursor-agent-delete-command-quote-parsing-wiped-windows-d-drive-chat-history-projects-first-person-forum}
}

Related cases

Medium Cursor coding agent

Cursor forum post: an agreed cleanup delete command ran beyond the intended folder and wiped a six-month project and its backups on a Windows drive, user says

In a bug report posted to the Cursor community forum on 3 October 2026, a user says that during a clean-up of a .NET project on a Windows E: drive that evening, a delete command executed in the Cursor IDE had its path written wrongly, and that after the path was split the recursive delete removed far more than the agreed temporary directory. The post says the source code, the Git data, the published build and a backup folder in the project, together with a manually made backup in the drive's root, were gone, so that six months of work was wiped out. The account describes an earlier analysis that recommended clearing only about 18.5 GB of compilation temporaries and the user agreeing to that batch. Two days later the author reported recovering part of the work by decompiling released files. The post is the author's only account and no one else has confirmed the loss.

Low Claude Code (reported)

Developer says a hands-free Claude Code session on Opus 5.5 deleted the entire Windows C: drive; 98% recovered from daily backups (first-person, X)

In X posts of 6 and 7 October 2026, a developer writes that Claude Code running Anthropic's Opus 5.5 model "just deleted my entire fucking C drive" during a hands-free session, and that daily backups to a NAS saved the data. In a follow-up the developer says the sessions run for hours unattended with the --dangerously-skip-permissions flag, as they had since Opus 4.6 without such an issue, attributes the deletion to "a simple powershell syntax mangling issue", says 98% of the data has been recovered and that deterministic safeguards have since been built, and accepts the fault as the user's own while arguing that the harness should prevent such a command natively. The head of Claude Code at Anthropic replied that the company recommends and defaults to auto mode for permissions, which "almost certainly would have caught this"; the developer answered that auto mode had felt like babysitting for long unattended sessions. The account is the developer's own. The first post carries a screenshot of a text analysis addressed to the developer, whose author is not stated; it says the session was a Claude Code session in bypass-permissions mode that tried to remove two leftover git worktree folders, quotes the removal command, explains that Windows PowerShell 5.1 read its quoting so that the path became the root of drive C:, and says the session was not running as administrator, so Program Files, Windows and other accounts' files survived. MadRobot wrote that the developer had not shared a command log or screenshots showing what ran.

Low Claude Code

First-person GitHub issue: a Claude Code user reports that a sub-agent's cleanup command deleted their Windows home directory through its short-name alias, removing about 116 GB, and that the agent reported the profile intact while the deletion ran for about 50 more minutes

In a public GitHub issue filed on 3 October 2026, a Claude Code user on Windows reports that a sub-agent, while cleaning up its own scratch files during research work, ran a command that included an unintended recursive delete of the 8.3 short-name alias of their home folder. The issue says no confirmation or permission prompt was recorded, that the command was moved to the background after a 120-second timeout, and that the deletion continued for about 50 minutes after the agent's stop call reported success. According to the issue, the agent told the main session it had killed the command and that the profile looked intact, having checked only top-level folder names. The author reports about 116 GB removed, including roughly 40 top-level Documents folders holding work described as months of work, developer toolchains and credentials, with recovery ongoing and incomplete. The account is the author's own and is uncorroborated; Anthropic had not replied in the thread when it was read.

Low Claude Code

Heritage project reports loss of inscription records after a Claude Code command

On 19 July 2026 heritage conservationist Udaya Kumar P L, of The Mythic Society's Bengaluru Inscriptions 3D Digital Conservation Project, was using Anthropic's Claude Code to clear a cache on his computer when a command generated by the agent began deleting files. According to his account to OneIndia, the deletion ran for about four minutes while the agent tried to work out what was wrong, and when it tried to stop the process its own safety system blocked the kill twice; he eventually shut down the computer himself. Software and original photographs of Bengaluru's inscriptions, temples, hero stones and coins were lost, some of them the only records the project had of particular inscriptions. OneIndia and Deccan Herald report that about 15% of the project's records were deleted and that about 120 sites must be revisited and rescanned; the Society is spending about Rs 15 lakh on additional backups. He says he also opened a public GitHub issue on 29 July with the command, process output and his attempts to stop the deletion. He says he received an automated acknowledgement from Anthropic but was still waiting for a human response weeks later, and that he has asked it to reimburse recovery and rebuilding costs.

If you or someone you know is struggling, free and confidential support is available. Find a helpline near you at Signpost.

Back to all incidents