Home / Errors / Cursor / agent-deleted-files

Cursor Agent Deleted My Files (Wiped Uncommitted Work)

Cursor Involved 30-90 minutes (recovery odds drop with every disk write) data risk Last verified Jul 17, 2026
The fix  Stop the agent and stop writing to that disk now: deleted files skip the Trash. Then recover in order: Cursor's Restore Checkpoint on an earlier prompt, the file Timeline (local history), git fsck for staged changes, git reflog for committed ones, then OS backups like Time Machine. Uncommitted changes discarded by git restore have no git object, so local history is your best shot.

Symptoms

  • You asked for something routine (clean up the repo, clone a project, scan a folder) and the agent ran 'git restore', 'git clean', or a recursive delete on its own.
  • Uncommitted changes silently vanish, with no prompt and no undo.
  • Whole project folders disappear; in the worst reported case, the agent's cleanup commands spiraled out and deleted files across the entire C: drive.
  • Deleted files are not in the Recycle Bin or Trash; they were removed directly from disk.

Why it happens

Auto-run executes commands without confirmation

With auto-run (formerly YOLO mode) enabled, the agent executes terminal commands without per-command confirmation, so a destructive command runs the moment the model generates it.

'Clean up' prompts pattern-match into destructive commands

The model turns routine requests into 'git restore', 'git clean', and recursive deletes, and Cursor's command safety checks do not reliably classify those as destructive. Cursor staff acknowledged agents running destructive git operations as a known issue in forum thread 154810.

git restore leaves nothing for git to recover

Uncommitted changes to tracked files discarded by 'git restore' have no git object at all, so git itself holds no copy to restore from. That is why local history and OS backups matter so much here.

How to fix it

  1. Stop the agent and freeze the diskCancel the running agent immediately and stop writing to the affected disk. Deleted files do not go to the Recycle Bin or Trash; they are removed directly from disk, and every new write reduces your recovery odds.
  2. Try Cursor's Restore CheckpointHover over an earlier prompt in the chat and click 'Restore Checkpoint' to roll the AI's edits back. Note that checkpoints cover the agent's edits, not the side effects of terminal commands it ran, so this may not bring back files a git or rm command destroyed.
  3. Check the editor's local historyRight-click the file and choose Open Timeline; VS Code and Cursor keep file snapshots there. You can also look directly in ~/Library/Application Support/Cursor/User/History on macOS or %APPDATA%\Cursor\User\History on Windows. For uncommitted changes wiped by git restore, this is usually your best remaining copy.
  4. Recover staged changes with git fsckIf the lost changes were ever staged with 'git add', git wrote blobs for them. Run 'git fsck --lost-found' and inspect .git/lost-found for dangling blobs containing your code.
  5. Use git reflog for anything that was committedIf the files were tracked and committed at any point, run 'git reflog' to find the last good state, then restore with 'git checkout <sha> -- path/to/file'.
  6. Fall back to OS backups, then disk-recovery toolsOn macOS, check Time Machine and APFS local snapshots with 'tmutil listlocalsnapshots /'. On Windows, check File History. Only after exhausting those, try disk-recovery tools. Honest note: uncommitted changes to tracked files that git restore discarded have no git object to recover from, so if local history and backups come up empty, that work is gone.

How to prevent it

  • Turn off auto-run for terminal commands in Cursor Settings > Agent, and add destructive commands to the denylist.
  • Commit or stash before letting the agent touch git; a committed file is one checkout away from safe.
  • Add a .cursor/rules entry forbidding destructive git and file commands without your explicit confirmation.
  • Treat 'clean up' style prompts as high risk; the model pattern-matches them into git restore, git clean, and recursive deletes.

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

Frequently asked questions

Do files deleted by the Cursor agent go to the Recycle Bin or Trash?

No. Files deleted by the Cursor agent's terminal commands are removed directly from disk, skipping the Recycle Bin on Windows and the Trash on macOS. That is why you should stop writing to the disk immediately and work through checkpoints, local history, git, and OS backups instead.

Can I recover uncommitted changes after Cursor ran git restore?

Sometimes. If the changes were ever staged with git add, 'git fsck --lost-found' can surface the blobs, and the editor's Timeline (local history) often has a snapshot. But uncommitted changes to tracked files that git restore discarded have no git object at all, so if local history and OS backups are empty, they are unrecoverable.

Is the Cursor agent deleting files a known bug?

Cursor staff have acknowledged agents running destructive git operations as a known issue in forum thread 154810. The command safety checks do not reliably classify 'git restore', 'git clean', or recursive deletes as destructive, so with auto-run enabled they can execute without a confirmation prompt.

How do I stop the Cursor agent from deleting files again?

Turn off auto-run for terminal commands in Cursor Settings > Agent, add destructive commands to the denylist, and add a .cursor/rules entry that forbids destructive git and file commands without explicit confirmation. Most importantly, commit or stash before every agent session so nothing valuable sits uncommitted.

Sources

Related errors

The Vibe Oops briefing

One email when something ships to production that should not have. New incidents, new error guides, no filler.