Critical Windows Data-Loss Incident — Cursor Agent Affected My D: Drive Without Any Instruction to Delete It — Aug 13, 2026

[K.J.H_K]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On August 13, 2026, while using Cursor Agent on Windows, a destructive operation affected data across my separate 1TB D: drive.

I want to state the most important fact clearly:

I never instructed Cursor to delete, erase, wipe, format, initialize, or destroy my D: drive.

The work I had instructed Cursor to perform concerned work on my C: drive. My D: drive was being used to preserve completed software projects, business materials, backups, and other important data.

I therefore need to understand how an Agent operation associated with work elsewhere could result in a destructive operation affecting data across a separate D: drive.

The incident caused severe disruption to active software-development and business projects.

I have preserved Cursor-related records and created a near-complete forensic image of the affected physical drive. Recovery and reconstruction work is ongoing and being documented.

I am not alleging intent. I am requesting a technical explanation of how this destructive operation occurred and why the available safeguards did not prevent it.

Steps to Reproduce

I will not intentionally attempt to reproduce this incident on a live drive because doing so could cause further destructive data loss.

At the time of the incident, I had instructed Cursor Agent to perform work related to my C: drive. I gave no instruction whatsoever to delete, erase, wipe, format, initialize, or otherwise modify my D: drive.

Nevertheless, during the Agent session, a destructive operation was executed, and data across my separate 1TB D: drive was deleted on a massive scale.

I have preserved relevant Cursor records, session information, recovery evidence, and a near-complete forensic image of the affected physical drive.

Because intentionally reproducing this incident could cause additional catastrophic data loss, I ask Cursor/Anysphere to use the preserved server-side and session records to reconstruct the exact command, execution path, resolved target path, and technical cause of the incident.

Expected Behavior

Cursor Agent should remain within the scope of the user’s requested task.

A development task associated with C: should never result in destructive modification or recursive deletion across an unrelated D: drive unless the user explicitly requests and confirms that exact operation.

If an Agent-generated command:

• targets a drive root such as C:\ or D:\,
• resolves outside the intended workspace,
• performs recursive deletion,
• changes target because of quoting, escaping, shell translation, or path-resolution behavior,
• or could affect data far beyond the intended folder,

Cursor should block the command or require clear, explicit user confirmation showing the fully resolved destructive target before execution.

A malformed or incorrectly resolved deletion command should fail safely rather than expand into drive-wide data loss.

Operating System

Windows 10/11

Version Information

IDE:

Incident date: August 13, 2026
Operating System: Windows 11

Exact Cursor IDE version at the time of the incident is currently being verified from preserved Cursor session/log records.

The currently installed Cursor version may differ from the version used at the time of the incident.

For AI issues: which model did you use?

Exact model used at the time of the August 13, 2026 incident is currently being verified from preserved Cursor session/log records.

I do not want to provide an unverified model name.

For AI issues: add Request ID with privacy disabled

The exact Request ID for the destructive operation is currently being recovered and verified from preserved Cursor records.

I request that Cursor/Anysphere also identify the Request ID and associated tool-call/session records from its retained server-side records for the August 13, 2026 incident.

Additional Information

I am writing this because I still cannot understand how work I requested on C: resulted in massive deletion on a separate D: drive where I had deliberately stored completed projects and backups for safety.

This incident is not a minor software malfunction.

I am a paying Cursor Pro user, and the affected 1TB D: drive contained completed software projects developed with Cursor Agent, core business materials, backups, project assets, and other work accumulated over a long period of time.

At the time of the incident, I had instructed Cursor Agent to perform work associated with my C: drive. I did not instruct Cursor to delete, erase, wipe, format, initialize, or destroy my separate D: drive.

Nevertheless, a destructive Agent operation affected data across that separate drive on a massive scale.

The incident has caused substantial disruption to my software-development work, business plans, project schedules, and recovery efforts.

I formally reported this incident to Anysphere and requested preservation of relevant records and a substantive technical explanation of the cause.

What concerns me greatly is that, before I received the detailed technical findings I requested regarding the exact command, execution path, resolved deletion target, and safeguards involved, the response I received relied in part on limitation-of-liability provisions.

I subsequently reviewed multiple serious Windows data-deletion incidents publicly reported in the Cursor Community during 2026.

In some of those discussions, Cursor personnel publicly discussed destructive shell commands, Windows quoting/path-resolution behavior, deletion extending beyond the intended target, limitations of existing protections, and related failure modes that had already been reported or were being tracked.

I am not claiming that every prior incident is technically identical to mine.

However, these prior reports raise a serious and unavoidable question:

If Anysphere was already aware that a Windows Agent shell command could, under certain conditions, expand beyond its intended deletion target and potentially affect a drive root or data outside the workspace, why was such a catastrophic operation still technically possible on August 13, 2026?

Why was a recursive destructive operation resolving to C:, D:, another volume root, the user home directory, or a location outside the intended workspace not hard-blocked or subjected to mandatory, explicit user confirmation showing the fully resolved target?

I also believe there is an important user-awareness issue.

If an Agent feature is capable of causing catastrophic local data loss despite existing safeguards, users should receive a prominent and explicit warning about that risk before allowing the Agent to execute destructive shell commands.

This becomes even more important where the company’s Terms may seek to substantially limit its financial responsibility after such a loss occurs.

I am not alleging here that Anysphere intentionally concealed information, and I am not asking this community to determine legal liability.

I am asking why a catastrophic risk that appears to have been discussed in multiple prior public incidents was not prevented at the product level or prominently disclosed to users before my incident occurred.

I have preserved Cursor-related records, session information, recovery evidence, and a near-complete forensic image of the affected physical drive.

Recovery and reconstruction are still ongoing.

I am also documenting the time and cost required to recover and rebuild the software and business assets affected by this incident.

I am still using Cursor only in a limited and closely supervised manner because I need it to assist with recovery and reconstruction.

That continued use should not be interpreted as meaning that the issue has been resolved or that I consider normal autonomous use safe.

I ask Cursor/Anysphere to provide a substantive technical response addressing:

1. The exact destructive command generated and executed.
2. The intended deletion target.
3. The actual target resolved by Windows.
4. The shell, working directory, quoting/escaping, and path-resolution process involved.
5. The Run Mode, approval state, and safeguards active during the incident.
6. Whether any safeguard detected or attempted to stop the destructive operation.
7. Whether my incident is related to, or technically distinct from, previously reported Windows destructive-deletion failure modes.
8. What product-level safeguard had been implemented before August 13, 2026 to prevent an Agent-generated recursive delete from expanding to a drive root.
9. Why that safeguard did not prevent this incident.

I will not publish private correspondence, confidential information, credentials, or settlement communications here.

My purpose in documenting this publicly is to establish an accurate technical record of my own incident, obtain a substantive explanation from Cursor/Anysphere, and raise a legitimate product-safety concern so that this type of catastrophic data loss is properly addressed.

I trusted Cursor enough to use it extensively as part of my actual software-development and business work.

I therefore expect a response consistent with the seriousness of the incident and the level of responsibility users should reasonably expect from the Cursor brand.

My dispute with Anysphere remains unresolved.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[K.J.H_K]

Follow-up Update — Additional Facts, Unanswered Questions, and Next Steps

I want to add several important facts and clarify the next steps I intend to take regarding this incident.

1. The D: drive was itself a backup and business-asset repository

One point needs to be made especially clear.

This was not a situation where I simply kept important files in one ordinary working folder and failed to make a backup.

The 1 TB D: drive that was affected was itself being used as a backup, archive, and long-term storage drive for important development and business materials.

At the time of the incident, I was preparing to establish and grow a startup/software-development business.

I was also preparing projects and documentation for Korean government startup-support programs and collecting and developing business and technology concepts that could potentially be used for future patent and intellectual-property work.

The D: drive contained, among other things:

• software-development backups;

• source code and project files;

• functioning or substantially developed MVP platforms;

• business concepts accumulated over time;

• startup and commercialization plans;

• materials being prepared for government startup-support programs;

• product and technology concepts being developed for possible future patent/IP protection;

• business models;

• technical architecture and documentation;

• planning and operational materials; and

• other proprietary business work.

Therefore, it would be inaccurate to characterize this simply as a case where a user failed to back up important information.

The drive that was destroyed was itself one of the locations specifically being used to preserve and back up those materials.

The loss therefore included backups themselves.

2. I did not instruct Cursor to do anything to D:

I want to eliminate any possible ambiguity about this.

I did not instruct Cursor to:

• delete D:;

• clean D:;

• reorganize D:;

• move files from D:;

• move files to D:;

• initialize D:;

• format D:;

• recursively delete files from D:; or

• otherwise perform file-management operations on D:.

More importantly:

I did not identify or mention D: as the target of the relevant task at all.

The work being performed concerned a different working context involving C:.

Nevertheless, Cursor Agent execution ultimately caused destructive activity affecting substantially all accessible data on my separate D: drive.

If Cursor/Anysphere believes that I ever designated D: as part of that operation, I am asking them to identify the exact user prompt in which I supposedly did so.

3. A C:-related task resulting in destruction of a separate D: drive requires more than “the AI made a mistake” as an explanation

I am not claiming a technical root cause that has not yet been proven.

However, I do not believe this incident can reasonably be dismissed merely as an ordinary AI misunderstanding or recognition error without a specific technical explanation.

The obvious engineering question is:

How did an Agent operation being performed in one storage/work context expand, resolve, or transform into a destructive operation against an entirely different drive that I had never identified as part of the task?

That requires investigation of issues such as:

• command generation;

• working-directory handling;

• path construction and resolution;

• quoting and escaping;

• shell interpretation or command transformation;

• recursive-delete safeguards;

• target-path validation;

• project and drive boundaries;

• permission boundaries;

• approval logic; and

• execution scope.

An AI can make a reasoning mistake.

But there is a separate product-safety question:

Why was that mistake technically capable of propagating into a destructive operation affecting an unrelated 1 TB drive?

That is the issue I am asking Cursor/Anysphere to explain.

4. I still have not received the substantive results of Anysphere’s investigation

Anysphere’s legal team informed me that they had investigated my case.

However, I still have not received substantive answers explaining:

• the exact command Cursor generated;

• the exact command ultimately executed;

• the intended target path;

• the actual target path;

• the working directory;

• the shell involved;

• whether quoting, escaping, path resolution, or shell interpretation contributed to the incident;

• why D: was reached despite not being identified as part of the task;

• why the operation expanded across such a large portion of the drive;

• what Agent/Cursor/model versions were involved;

• what approval state existed;

• which safety protections were actually active;

• whether those protections could technically intercept the execution path that caused the deletion; and

• what Anysphere considers the actual root cause.

I have also repeatedly requested confirmation that relevant evidence has been placed under a legal hold, preservation hold, or equivalent measure.

I have not yet received a direct Yes/No confirmation.

5. Previous similar incidents remain relevant

I have preserved public Cursor Community reports that pre-date my August 13 incident and describe materially similar Windows destructive-file incidents.

I am not claiming that every prior incident is technically identical to mine.

However, some prior reports involved Windows shell commands, recursive deletion, quoting/path problems, unintended expansion outside the target directory, drive-root exposure, and very large amounts of data loss.

Some Cursor responses to those reports indicated that related failure modes were known, reported internally, or being tracked.

For that reason, I have asked Anysphere whether my incident represents:

• recurrence of the same or a similar failure class;

• a technically different failure; or

• a failure that has not yet been classified.

That question also remains unanswered.

6. My concern now extends beyond the loss of software source code

The affected D: drive contained not only development files but also accumulated business-development material.

I was preparing a startup-development business.

I was preparing for government startup-support opportunities.

I was also collecting and developing product and technology ideas for potential future intellectual-property and patent work.

That makes the scope of this incident significantly more serious than losing a disposable build directory or temporary project folder.

It affected an archive containing a substantial amount of accumulated technical and business work.

7. I am preparing a more detailed formal notice if this cannot be resolved directly

I still prefer to resolve this directly and professionally with Anysphere.

However, because many of the central questions remain unanswered, I am preparing a more detailed formal record covering:

• the complete incident chronology;

• my actual instructions;

• evidence showing that D: was not part of the requested task;

• the destructive command and terminal evidence;

• forensic and recovery results;

• affected software and business assets;

• prior similar public incident reports;

• unresolved safety questions;

• reconstruction requirements;

• actual and developing damages; and

• the relief requested.

If direct resolution is not possible, I intend to send a formal Notice of Dispute to the appropriate Anysphere legal entity and headquarters in accordance with the applicable dispute-resolution procedure, in preparation for possible American Arbitration Association (AAA) proceedings.

I am mentioning this here for transparency about the procedural steps I am taking.

I would still prefer to receive meaningful technical answers and attempt a good-faith resolution before that becomes necessary.

8. I also need clarification following the reported SpaceX acquisition

I have learned from public reporting that the SpaceX acquisition of Anysphere/Cursor was completed immediately after this incident.

My incident occurred on August 13, 2026.

The reported acquisition closing occurred the following day.

Because this claim arose before the closing but remains unresolved afterward, I am asking Anysphere to clarify an important procedural issue:

Who is now the legally responsible entity and official legal contact for this pre-acquisition Cursor incident?

I am specifically asking for written confirmation of:

• whether Anysphere, Inc. remains the entity responsible for handling this claim;

• whether Ticket T-E80825 remains an Anysphere legal matter;

• whether Anysphere remains the proper respondent for a future Notice of Dispute and potential AAA proceeding;

• whether SpaceX has assumed or succeeded to any relevant obligations or liabilities;

• whether future formal notices should be sent to Anysphere, SpaceX, or both;

• the correct current legal name and mailing address for formal notice;

• the correct legal or claims representative handling this matter;

• whether [email protected] remains the authorized legal contact;

• whether my prior evidence-preservation requests remain fully effective after the acquisition; and

• which entity now has custody or control of the relevant Cursor logs, engineering records, incident records, and other evidence.

I am not asserting without evidence that SpaceX itself is legally responsible for my loss.

I am asking for clarity so that a corporate acquisition completed immediately after the incident cannot later create confusion over which entity was required to receive notice or respond to the claim.

9. I still want a responsible resolution

I used Cursor extensively because I trusted the product.

I understand that AI systems can make mistakes.

The issue for me is not whether an AI can ever make a mistake.

The issue is what happens when an autonomous coding agent makes a mistake with enough system authority to cause catastrophic real-world damage.

And equally important:

How does the company respond afterward?

Does it determine the root cause?

Does it preserve the evidence?

Does it explain why the safeguards failed?

Does it investigate whether the same problem happened before?

Does it help the affected user recover?

Does it take responsibility where responsibility is supported by the evidence?

Does it implement safeguards to prevent the same incident from happening to another user?

Those are the answers I am still waiting for.

I remain willing to resolve this directly and professionally.

But I am asking Cursor/Anysphere to provide the substantive technical and procedural answers that have not yet been provided.

Ticket: T-E80825
Incident: August 13, 2026, approximately 9:00 AM KST
Affected storage: Samsung SSD 970 EVO 1 TB / D:

[kevinn (Kevin Neilson)]

Hi @K.J.H_K Thank you for the post. Please reach out to [email protected] where we can help you on an individualized basis.