Critical incident: Cursor agent left repository and deleted local Documents folder

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Today I experienced a critical incident with Cursor’s AI agent. The agent moved outside the intended repository and executed actions that affected my Windows system, including modifying paths/system files, deleting stored Windows credentials, damaging installed programs, and deleting my Documents folder containing important local source code.

I have preserved the Cursor logs related to the incident and need this escalated to Cursor’s technical/security team. I am not posting full logs publicly because they may contain sensitive information, but I can provide them securely to Cursor staff.

Please advise how to submit the logs securely and how Cursor can review the internal records associated with my session.

Steps to Reproduce

I cannot safely reproduce this intentionally because the issue caused destructive changes and deleted important local files.

The incident happened while using Cursor IDE Agent on Windows with a local repository open. The agent was expected to work only inside the opened repository, but during execution it appears to have moved outside the repository scope and performed actions affecting my Windows environment.

After the agent execution, Windows paths/configurations were modified, stored Windows credentials were deleted, some installed programs were affected, and most critically, my Documents folder containing important local source code was deleted.

I still have Cursor logs from the session and can provide them securely for investigation.

Screenshots / Screen Recordings

Captura de pantalla 2026-04-24 191121.png
Captura de pantalla 2026-04-24 191121.png917×476 37.4 KB

Operating System

Windows 10/11

Version Information

Version: 2.6.22 (system setup)
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

auto

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report.

About the incident. What you’re describing, the agent running destructive shell commands outside the repository, is a known issue. A few important notes about the agent’s safety boundaries, so it’s clear what happened:

  • External-File Protection only limits file editing and writing tools. It does not apply to terminal commands like rm, Remove-Item, rmdir /s /q, git clean -fdx, and similar.
  • On macOS there’s an extra sandbox layer called Seatbelt. On Windows there’s no equivalent, so if the agent is allowed to run a command, it will run with your user permissions anywhere on the disk.
  • If Auto-Run is enabled, or if a destructive command is on the allowlist, the agent will run it without confirmation.

What I recommend doing right now while you’re using Cursor on this machine:

  1. Turn off Auto-Run Mode in Settings → Chat → Auto-Run, or heavily restrict the Command Allowlist and remove any delete, move, or git cleanup commands.
  2. For risky tasks like filesystem refactors, migrations, or cleanup scripts, use Cloud Agents, a dev container, or a VM instead of a local machine with sensitive data.
  3. Make sure your important local folders are under Git or backed up before running the agent.

Related threads for context: The cursor completely formatted my C drive The cursor completely formatted my C drive while I was running the project, Cursor deleted files across my entire system Cursor deleted files across my entire system – critical issue, Cursor default Auto-Run Mode Command Allowlist is recklessly dangerous Cursor default "Auto-Run Mode" "Command Allowlist" is recklessly dangerous.

I can’t share an ETA for changes in this area right now.

6

The dangerous part about this is that you might accept a command like:

cmd /c "xcopy /e /i /y src\app\[locale]\(auth)\(auth)\forgot-password src\app\[locale]\(auth)\forgot-password >nul & xcopy /e /i /y src\app\[locale]\(auth)\(auth)\invitation src\app\[locale]\(auth)\invitation >nul & xcopy /e /i /y src\app\[locale]\(auth)\(auth)\register src\app\[locale]\(auth)\register >nul & xcopy /e /i /y src\app\[locale]\(auth)\(auth)\reset-password src\app\[locale]\(auth)\reset-password >nul & xcopy /e /i /y src\app\[locale]\(auth)\(auth)\verify-email src\app\[locale]\(auth)\verify-email >nul"

$ cmd /c "xcopy /e /i /y src\app\[locale]\legal\legal\* src\app\[locale]\legal\ >nul & rmdir /s /q src\app\[locale]\legal\legal"

These commands look harmless, but the agent strayed from its objective to mess with sensitive information on my computer. It was trying to recover files that it had deleted itself, and it ended up affecting me.

The dangerous part is that a command like rmdir /s /q can cause damage to the OS (modifying Windows rules, changing directories, deleting programs) and also delete files that are not in the directory where you are working.

While our code is generally backed up in Git, it is extremely dangerous for the Cursor agent to interfere with other files and delete personal data and credentials from a PC. This is a critical security risk that must be addressed; they need to step up and take responsibility for the damages caused by this malfunction

7

Hey, that’s a fair follow-up question, and the example you gave shows the core issue well. A command chain can look like a harmless xcopy, but still end with rmdir /s /q. Then it only takes one quoting mistake or one path expansion/substitution issue for the deletion to happen somewhere else than intended. The [locale] and (auth) parts in your command are exactly the kind of symbols that cmd.exe and PowerShell handle inconsistently.

We’re aware of this class of issues, and similar reports are already tracked internally, including Windows-specific behavior around quotes and escaping.

In the meantime, the practical steps are the same as in my previous reply, and you should treat them as required on any Windows machine with personal data:

  • Turn off Auto-Run or remove anything that deletes, moves, or “cleans” from the allowlist of commands (rm, rmdir, Remove-Item, git clean, xcopy /y when it’s chained with deletes, etc.). Then the agent will ask for confirmation before running it.
  • For destructive operations or big refactors, run the work in a Cloud Agent, a dev container, or a VM, not on the host machine.
  • Keep your work in Git and also make separate backups of Documents.
16

@Faber_Londono, for a safe way to share logs, email [email protected]. The team will review the incident privately, without posting details in the thread.

@DoNotTrustVibeCoding, a binary yes or no on the record framing mixes different threat models. Classic ACE or RCE is unauthenticated remote code execution with no user involvement. This is a different model. The agent runs shell commands only within what the user explicitly allowed. Auto-Run is opt-in, the allowlist is controlled by the user, and by default commands require confirmation. That doesn’t reduce how serious the impact can be when a destructive command slips through. We get that, and improving model safety around shell usage is an area the team is working on.

The steps I listed above, like turning off Auto-Run, removing delete or move or git clean from the allowlist, and running risky work in Cloud Agents or a VM or a dev container, aren’t cosmetic. They meaningfully reduce risk. I won’t give an ETA or make promises about a timeline for changes.