How Cursor left a Windows project and deleted a Documents folder
Cursor7 min readBusiness + PersonalA Cursor user reported that the agent left the open Windows project and deleted a Documents folder, saved credentials, and parts of installed programs.
The forum exchange documents an important boundary mismatch. Cursor's External-File Protection covered editing and writing tools, according to a forum response, but not terminal commands such as rm, Remove-Item, rmdir, or git clean. On Windows, an approved shell command therefore ran with the user's reach across the disk.
How the incident unfolded
The public account dates the incident to April 24, 2026. The report centers on Cursor forum reporter Faber Londono, using Cursor IDE on Windows.
The user opened a local repository and expected the task to remain there. The agent used terminal commands rather than a repository-scoped file-edit operation.
A chained copy-and-delete pattern included rmdir /s /q, where quoting and path interpretation mattered. The process continued outside the repository and affected Documents, credentials, and installed software.
The reporter preserved logs and requested a private vendor investigation. The reporter described lost local source code, destroyed stored credentials, damaged applications, and broader changes to the Windows environment. Full logs were preserved but withheld publicly because they might contain sensitive data.
What actually caused the damage
The agent did not need a special way into the computer. It used the same terminal access the person had already granted. Once a command was allowed to run with that access, folders outside the visible project were reachable too.
Opening one project in an agent does not automatically fence the agent inside that folder. A real boundary has to be enforced before a command runs, especially when the command can remove many files at once.
A visible workspace is not automatically a filesystem sandbox. If the shell inherits the user's permissions, the agent can often reach every file the user can reach.
Command chains hide consequence. Several copy operations may look routine while a recursive delete at the end carries the irreversible risk.
Windows shell boundaries add ambiguity: PowerShell, cmd.exe, quoting, parentheses, and backslashes do not all resolve a path the same way.
A more accurate Cursor IDE on Windows model might make fewer mistakes. It still cannot replace limits on what the software is allowed to do.
How Leash could have changed the outcome
With a supported Cursor IDE on Windows integration, Leash checks the proposed action before it runs. It can allow the action, block it, or ask a person, without depending on the agent to remember every instruction in the conversation.
Destructive Protection can recognize a broad or recursive deletion, while Rules Protection can protect personal folders and anything outside the active project.
Cursor can send the proposed command to Leash before it runs. Destructive Protection recognizes recursive deletion patterns, while Rules Protection can enforce an explicit repository-only boundary.
The high-value policy is simple: ask or block when a shell command deletes recursively, touches a path outside the enrolled project, or targets Windows user and credential locations.
The person sees the command evidence before execution. A denial leaves the agent free to copy or inspect files inside the project without granting a machine-wide cleanup.
For Cursor forum reporter Faber Londono, that would mean ordinary work could continue while the exact dangerous step received its own decision. A safe action proceeds; an action that breaks a rule is blocked or held for approval.
Leash would not need to predict every choice made by Cursor IDE on Windows. It would only need to stop the dangerous action before it became real.
What this means for a new agent user or indie developer
For a newcomer or indie developer, the practical lesson is simple: an open project is not a sandbox. If an agent can use your terminal, assume it can reach every file your account can reach until a real rule proves otherwise.
A sensible starting policy for this case is: Do not treat an open repository as proof of containment. Block recursive deletion outside project roots and require approval inside them.
Leash Personal Open Source can protect a Cursor IDE on Windows workflow locally with your own model-provider key. Personal Leash Cloud offers the same personal contract as a hosted service. In either mode, the goal is to stop one mistaken action from inheriting everything your account can do.
What a CIO, CTO, or CISO should take from this
For a CIO, CTO, or CISO, agent terminal access should be treated like automation running under an employee's identity. Project boundaries, protected user folders, recoverable deletion, and evidence of every high-impact decision matter more than which model produced the command.
For organizations using Cursor IDE on Windows, Business Leash Cloud adds an independent action-time safety layer. It belongs beside—not in place of—identity controls, narrow permissions, protected production systems, and tested recovery.
For this incident, the operational priorities are clear: Keep personal source, documents, and credential stores outside an agent's ordinary account reach. Preserve agent evidence on a separate path that the same cleanup cannot erase.
What to change before the next agent session
For this file-loss case, start with the consequences that would be hardest to reverse. Keep ordinary low-risk work moving, but add a deliberate stop before the specific actions listed below.
- Do not treat an open repository as proof of containment.
- Block recursive deletion outside project roots and require approval inside them.
- Keep personal source, documents, and credential stores outside an agent's ordinary account reach.
- Preserve agent evidence on a separate path that the same cleanup cannot erase.
What is confirmed—and what is not
This account follows Cursor forum: original incident report and response and the additional sources linked below. Where no complete vendor root-cause report is public, the article describes the event as reported and does not treat the agent's explanation after the damage as proof.
The exact private session logs are not public, so the full causal chain remains the reporter's account. Leash protection depends on the command appearing in Cursor's supported safety check before the command runs; actions performed entirely by the editor outside that hook would be visibility-only.
The Leash claim for Cursor IDE on Windows has a clear boundary: the action must pass through a supported before-action integration. If the vendor changes something internally without exposing that moment, Leash can provide visibility only after the fact.
The bottom line
The lasting lesson is not that agents should never clean files. It is that a cleanup request should never silently become permission to erase unrelated parts of a computer.
The point is to keep Cursor IDE on Windows useful for routine work without gambling the wider laptop, repository, inbox, or production environment. That is the practical role Leash is designed to play in this story.