Skip to main content
NOPE
Medium reported severity

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.

AI system
Cursor coding agent
Cursor
Occurred
3 Oct 2026
Reported
3 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
Work
Evidence
AI involvement reported · Causal attribution alleged · 1 source
4 claims: 4 reported. 6 open questions
People reported harmed
1 person

AI system as recorded: The AI coding agent in the Cursor IDE, which the post says executed a Windows rmdir /s /q command through cmd on the E: drive; the report's form answer to 'which model did you use?' is Grok 4.7

What Happened

The post. The report is filed under 'Cursor IDE' and opens: "Cursor made a serious error: when executing the delete command, it not only deleted my current project, but also deleted the entire hard drive partition, including the source code backup I manually made, resulting in the project of 6 months being wiped out." The steps section is written in the second person, addressed to the user, and ends by advising the user to submit a complaint to Cursor; the post does not say who wrote that text. In a follow-up four minutes later the author wrote in their own words: "AI executed the rmdir command".

What happened, per the post. On the evening of 3 October 2026 the user asked for an analysis of which directories under the project folder on E: could be deleted and "explicitly stated to wait for your instructions". The analysis said to "only clear the compilation temporary directory, approximately 18.5 GB" and to leave the backup folder, recovery copies, source code, publish folder and Git untouched. At 8:50 PM the user replied "Okay, follow the recommendation and delete them", "agreeing to this batch". Then "a command had the wrong path written": a cmd /c rmdir /s /q command quoting a path under the project folder. "rmdir /s /q does not go to the Recycle Bin. After the path was split, far more than just that temporary directory was deleted."

Reported loss. The source code, Git, publish and backup folders in the project were gone, and "The ERP system backup (compressed file and logs) you manually made in the root directory of the E drive" and a packaging script were also gone. "The entire hard drive was not formatted, but your six months of engineering and manual backups were cleared by this command. What the analysis explicitly stated to keep was not kept." What remained were a bin folder locked by the running program, Program Files and SQL data.

Recovery. A forum member suggested stopping writes to the drive, checking Git remotes, Cursor's local history and recovery tools. On 5 October the author wrote: "I have already compiled the released files, decompiled them, and recovered a part of them."

Limits. Single first-person forum account, uncorroborated. The report's form answer to 'which model did you use?' is Grok 4.7, and the author asks 'Could it be because of the new model?'. The post does not say whether the command ran with or without a per-command approval, or how the path came to be split. No country is stated; a Chinese-language script filename does not establish one. The author's forum handle is not recorded.

Reported harm

The user reports that a recursive delete command executed in the Cursor IDE, agreed for a roughly 18.5 GB temporary directory, ran with a wrongly written path and removed the project's source code, Git data, published build and backup folder plus a manual backup in the drive root, wiping six months of work, part of which was later recovered by decompiling released files (first-person forum post, uncorroborated).

Outcome

Ongoing

On 5 October 2026 the author replied that they had compiled the released files, decompiled them and recovered part of the work. The thread had five visible posts when read on 8 October 2026; no Cursor staff reply appears in it. The post reports that the drive was not formatted and that a locked bin folder, Program Files and SQL data on the drive remained.

What remains unknown

  • Whether the command ran with a per-command approval.
  • How the command's path came to be split.
  • Who wrote the second-person account in the report; the post does not say.
  • How much of the work was recovered.
  • Where the author lives.
  • Whether Cursor responded to the report.

What the evidence supports

AI involvement: reported. The post states that the AI in the Cursor IDE executed the rmdir /s /q command: the author's own follow-up says 'AI executed the rmdir command', and the report's step-by-step account says the delete command had a wrongly written path and, after the path was split, deleted far more than the agreed temporary directory, including the source code, Git data, backups and a manual backup in the drive root. The post connects that command to the loss of six months of work. No one other than the author has confirmed the command or the loss.

4 claims: 4 reported. What the statuses mean

Reported The post reports that on the evening of 3 October 2026 the user agreed to a clean-up limited to about 18.5 GB of compilation temporaries after an analysis that said to leave the backups, source code, publish folder and Git untouched, that a delete command was then written with the wrong path, and that after the path was split the recursive delete removed far more than the agreed temporary directory.

Causal attribution. The post attributes the command to the AI in the Cursor IDE: 'AI executed the rmdir command'.

  • forum.cursor.com(opens in new tab) supports · English
    'On the evening of October 3, 2026'; 'only clear the compilation temporary directory, approximately 18.5 GB'; 'agreeing to this batch'; 'Subsequently, a command had the wrong path written'; 'After the path was split, far more than just that temporary directory was deleted'
Reported The post reports that the project's source code, Git data, publish and backup folders and a manually made backup in the drive root were gone, that six months of engineering and manual backups were cleared by the command, and that the drive was not formatted.

Causal attribution. User's account; uncorroborated.

  • forum.cursor.com(opens in new tab) supports · English
    'resulting in the project of 6 months being wiped out'; 'you manually made in the root directory of the E drive'; 'The entire hard drive was not formatted, but your six months of engineering and manual backups were cleared by this command'
Reported The author's follow-up states that the AI executed the rmdir command on an SSD and asks whether the deleted files can still be recovered.

Causal attribution. Author's own attribution.

Reported Two days after the report the author said they had compiled the released files, decompiled them and recovered part of the work.

Causal attribution. Not applicable.

Sources

1 source 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-08 through the forum's JSON endpoint: the opening post and four replies (two by the author, two by other members). The post is in English with one Chinese-language script filename, which the research agent (an AI) read without translation. The author's handle is not recorded. Applies to s1.

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

The post does not say where the author was or lives; a Chinese-language script filename and the forum handle do not establish a country. No country is recorded.

Reviewed for publication 2026-10-08: Published under the charter's public first-person rule as a concrete account of an AI coding agent's delete command removing a user's project and backups, with the command and the loss attributed to the author's post, the partial recovery attributed to the author's later reply and the account uncorroborated. The author's handle is not recorded.

People described

The post's author, a Cursor user working on a .NET ERP project on a Windows E: drive

People reported harmed in this case

1 person

1 AI participant · 0 other people harmed

One person: the post's author. 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#backup-loss

Cite this case

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

APA

NOPE. (2026). 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. AI incidents. https://nope.net/incidents/2026-cursor-agent-cleanup-delete-command-split-path-wiped-six-month-project-and-backups-windows-drive-first-person-forum

BibTeX

@misc{2026_cursor_agent_cleanup_delete_command_split_path_wiped_six_month_project_and_backups_windows_drive_first_person_forum,
  title = {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},
  author = {NOPE},
  year = {2026},
  howpublished = {AI incidents},
  url = {https://nope.net/incidents/2026-cursor-agent-cleanup-delete-command-split-path-wiped-six-month-project-and-backups-windows-drive-first-person-forum}
}

Related cases

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.

Medium Google Antigravity (suspected)

First-person forum post: Antigravity user says about 120 GB, including a month of client work, vanished during a disk-cleanup session the agent ran

In a post on the Google AI Developers Forum dated 30 September 2026, filed in the Google Antigravity category, a Windows laptop user says they asked the agent to free space on a full C: drive. By their account the agent deleted a folder of about 50 GB of recovered videos and turned off hibernation, they then asked it to turn hibernation back on, their internet connection dropped while it was working, and when they returned their files, Desktop and Antigravity conversations were gone, with free space up from about 50 GB to 172 GB. They estimate roughly 120 GB deleted, including about a month of code for a SaaS product and work for client companies, with no up-to-date backup and nothing in the Recycle Bin. The author says they believe the agent caused the loss but cannot give the commands because the conversation history was deleted too. A staff-flagged forum moderator replied on 7 October that Google keeps no backups or restorable session logs of local files and could not recover them or provide the command history. The account is uncorroborated.

Low Claude Code

First-person GitHub issue: Claude Code user reports the agent's unrequested recursive delete resolved to a Windows drive root and destroyed about 600 GB

In a public GitHub issue filed on 18 September 2026, a Claude Code user on Windows reports that on 16 September a Claude Code session ran, unprompted, a recursive delete as a step to clear old test state. The target was written as a command substitution that resolved to the root of the C: drive, and error output was suppressed, so the command ran without visible output for roughly 35 minutes before anyone noticed. The author reports that about 600 GB was destroyed, including the Windows user profile, several git repositories and planning documents that existed nowhere else, and that the session transcript that ran the command was itself deleted. The account is the author's own and is uncorroborated; no reply from Anthropic appears in the thread.

Low Google Antigravity

First-person forum post: a Google Antigravity user reports the agent's deletion command, meant for temporary folders, wiped the root of their Windows C: drive

In a thread on Google's AI developer forum posted on 22 July 2026, a Google Antigravity user on Windows 11 reports that on 21 July the agent, during a long-running data-mining and download workflow, ran a deletion command aimed at the root of the C: drive after the user had asked it to delete specific temporary working folders. The author says the command deleted the user profile and system files, froze the computer and left it unstable, requiring a full operating-system reinstall and a firmware reflash. The first post says the command ran without human confirmation. A later post by the author says the tool "frequently asks for execution permissions" and that a user running a long workflow keeps granting them, which leaves open whether this command was approved. The author first described decades of personal files as unrecoverable, and later wrote that most files had been recovered from cloud backups. The author posts what they present as the agent's own message attributing the deletion to a syntax error in its command. Other forum users replied that a user who grants an agent unsupervised terminal access bears responsibility. The account is the author's own and is uncorroborated.

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