Recover Files After Cursor Agent Deletes Them (2026)

Cursor's AI agent deleted your project files — and the fastest path back depends entirely on which deletion scenario you hit. This guide gives you a triage checklist, ordered from the fastest fix to the last resort, so you can start with the method most likely to work for your specific situation. Stop writing new data to the affected drive right now, before you do anything else.

Part 1. Why Cursor Agent Deletes Files (and Why It Happens More Than It Should)

Cursor's agent operates directly on the file system, which means it can remove or empty files faster than any undo stack can track. There are four well-documented scenarios where this goes wrong, and knowing which one hit you determines where to start your recovery.

Four known deletion scenarios:

1. Agent removes "unused" files during refactoring — The agent classifies certain files as duplicates or dead code and deletes them without confirmation.
2. "Undo All" in Composer wipes the session — Clicking "Undo All" reverts every file the agent touched in that Composer session, often removing them entirely.
3. Cursor 1.3 undo bug — Pressing Undo on any file the agent had edited triggers a bug that empties or deletes the file instead of restoring it.
4. "Restore Checkpoint" bug on Mac — Restoring a checkpoint deletes all files the agent visited during that session, rather than reverting their content.

A critical detail that affects every recovery method below: Cursor does not send deleted files to the OS Recycle Bin. Files are removed directly from disk. Check the Recycle Bin first, but if the files are not there, move immediately to the steps in this guide.

��️ forum.cursor.com user: "I accidentally clicked 'Undo All,' which deleted all project files. They were still visible in the review along with the code, but I could no longer click 'Accept All.'"

Table 1: Common Cursor Agent Deletion Scenarios

Scenario	How It Happens	How to Identify It	First Recovery Step
Agent deleted "unused" files	Agent refactored and removed files it classified as duplicates	Files missing after a refactor session; no Recycle Bin entry	Cursor Checkpoints (Part 3)
"Undo All" clicked accidentally	User clicked "Undo All" in Composer panel	Files vanished immediately after clicking; still visible in Composer review	Cursor Checkpoints (Part 3)
Cursor 1.3 undo bug	Pressing Ctrl+Z on agent-edited file empties or deletes it	File is blank or gone after a single Undo keystroke	Local History (Part 4)
Restore Checkpoint bug (Mac)	Restoring a checkpoint deletes all files the agent visited	Files missing after clicking Restore on a checkpoint	CursorRecovery tool (Part 6)
Agent deleted project on revert	Agent reverted changes and removed files it had created or modified	Entire sections of project gone after a session revert	Git reflog (Part 5)

Part 2. Before You Do Anything — Stop Making It Worse

Every file written to the drive after a deletion reduces the chance that data recovery software can find the deleted data. The steps in this section take under two minutes and may be the difference between a full recovery and permanent data loss.

Do not do any of the following until you have completed your recovery attempts:

• Save new files to the drive where your project was stored
• Run the Cursor agent again on the affected project
• Install new software on the affected drive
• Restart your machine if Cursor is still open (Checkpoints do not survive restart)

⚠️ Important: If your project was stored on the C: drive, avoid heavy activity on that drive — browser cache writes, Windows Update, and large downloads all write data that can overwrite your deleted files. Prioritize recovery before returning to normal computer use.

Check the Recycle Bin first. Cursor typically bypasses it, but in some configurations or with certain file operations, files may land there. If the Recycle Bin is empty, proceed to Part 3.

Part 3. Recovery Step 1 — Cursor Checkpoints (Fastest, Try First)

Cursor automatically creates a checkpoint at the start of each Composer prompt. These checkpoints act as instant snapshots of your project state and are the fastest path to recovery if Cursor is still running from the session when the deletion occurred.

How to use Checkpoints:

1. Open the Composer panel (the same panel where you issued the agent prompt)
2. Scroll up in the conversation history to find a "Checkpoint created" message
3. Click Restore next to the checkpoint that predates the deletion

�� Tip: If Cursor is still open from the session when the deletion happened, check Checkpoints before doing anything else. Do not close or restart Cursor until you have confirmed whether a usable checkpoint exists — Checkpoints do not persist after Cursor restarts.

When Checkpoints work:

• The deletion happened during a Composer session and Cursor is still running
• You can identify the checkpoint that predates the bad agent operation

When Checkpoints do NOT work:

• Cursor has been restarted since the deletion
• The deletion happened in Agent mode tab completions (not a Composer session)
• More than one session has run since the deletion, and the relevant checkpoint has been pushed out

If Checkpoints are unavailable, move to Local History in Part 4.

Part 4. Recovery Step 2 — Cursor / VS Code Local History

Cursor is built on VS Code and inherits its Local History feature. Cursor quietly saves versioned snapshots of every file you open in the editor. This hidden directory survives both agent deletions and Cursor restarts, making it the most reliable first fallback when Checkpoints are gone.

How to access Local History:

1. Press Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (Mac) to open the command palette
2. Type "Local History: Find Entry to Restore" and press Enter
3. Browse the list of saved entries and open each one to identify the version you need

Important limitation: Local History stores files with URL-encoded paths and aliased file names — the displayed names will not match your original file names. You will need to open each entry individually to identify the right version by its content.

💡 Tip: If you are recovering many files from Local History and the aliased names are slowing you down, try the CursorRecovery Python tool — it automates the decoding process and maps entries back to their original file paths.

When Local History does NOT work: Local History only covers files that were opened in the Cursor editor at least once. If the agent deleted files it never opened — for example, files it identified as unused from a directory listing — Local History may have no entry for them.

🗣️ forum.cursor.com user: "Hours of work just wasted, and how do I recover my deleted file." — This user ultimately recovered the file using the Local History feature after Checkpoints were unavailable.

If Local History has no entry for the missing files, check Git in Part 5.

Part 5. Recovery Step 3 — Git and Git Reflog

If your project uses Git, version history may already contain the files you need — even if you never committed manually. Cursor writes autosave commits to the Git reflog, which can serve as restore points that predate the agent's destructive operation.

Standard Git recovery commands:

# See all changed or deleted files
git status

# Review what changed in a specific file
git diff HEAD -- path/to/file

# Restore one deleted file from the last commit
git checkout HEAD -- path/to/file

# Full project rollback to last commit
git checkout HEAD -- .

💡 Tip: Even if you did not commit manually, Cursor's autosave commits in the reflog can serve as restore points. Run git reflog --all and sort by timestamp to find a commit that predates the deletion.

Finding and using Cursor autosave commits:

# Find Cursor autosave commits in reflog
git reflog --all | grep 'cursor-autosave'

# Restore a specific file from an autosave commit by timestamp
git checkout HEAD@{'2026-05-01 14:23:00'} -- path/to/file

Table 2: Git Recovery Commands

What You Need	Command	Notes
See all changed/deleted files	git status	Shows tracked changes vs HEAD
Review file changes	git diff HEAD -- path/to/file	Confirms what was altered
Restore one file from last commit	git checkout HEAD -- path/to/file	Safe — only touches one file
Find Cursor autosave commits	git reflog --all | grep 'cursor-autosave'	Lists all autosave restore points
Restore from autosave by timestamp	git checkout HEAD@{'YYYY-MM-DD HH:MM:SS'} -- path/to/file	Replace timestamp with reflog entry
Full project rollback	git checkout HEAD -- .	Restores all tracked files to HEAD

Limitation: If you never committed and Cursor's autosave did not run before the deletion, Git has nothing to restore from. In that case, move to the CursorRecovery tool in Part 6.

Part 6. Recovery Step 4 — The CursorRecovery Tool

When Local History has entries but the aliased file names make manual recovery impractical at scale, the CursorRecovery tool automates the process.

What it does: CursorRecovery extracts file version history directly from Cursor IDE's local VSCode SQLite database. It decodes the URL-encoded paths, matches entries to their original file names, and outputs an organized folder of previous file versions.

When to use it:

• Local History has entries but manual name-matching is too slow for dozens of files
• The Cursor SQLite database is still present on your machine (it typically is, even after agent deletions)
• You need to recover multiple files from a single session

Requirements:

• Python installed on your machine
• The Cursor SQLite database still on your machine (check %APPDATA%\Cursor\User\History on Windows)
• Git — the tool clones from GitHub

💡 Tip: Run CursorRecovery before attempting any disk-level recovery. If the SQLite database is intact, it may recover every file from the session in one pass, making data recovery software unnecessary.

Output: An organized folder of previous file versions, matched to their original file paths, sorted by timestamp.

Part 7. Recovery Step 5 — Data Recovery Software (Last Resort)

If Checkpoints are gone, Local History has no entry, Git reflog is empty, and CursorRecovery returns nothing, data recovery software scanning the raw disk may still find your files.

Why it can still work: When Cursor deletes files directly to disk — bypassing the Recycle Bin — Windows removes only the file system entry that points to the file. The raw file data typically stays on disk until new data is written to the same sectors. Data recovery software scans at the sector level to find and reconstruct that data.

Two rules that apply before you run any recovery software:

1. Stop writing new files to the affected drive immediately (covered in Part 2)
2. Install recovery software on a different drive than the one being scanned — installing to the same drive risks overwriting the very data you are trying to recover

⚠️ Important: If your project was on the C: drive, install recovery software to an external USB drive or a secondary internal drive. Running the installer on C: may permanently destroy the deleted file data before the scan can find it.

Source code files — .js, .ts, .py, .html, .css, .json, .md — are standard text files. Data recovery software can locate them on Windows drives as long as the storage has not been heavily overwritten since the deletion.

Part 8. Ritridata Recommendation

When Cursor's agent deletes local project files on Windows and built-in recovery options have been exhausted, Ritridata is a data recovery tool designed to scan Windows storage at the raw sector level for deleted file data. It supports recovering source code files — .js, .ts, .py, .html, .css, .json, .md — from Windows HDD and SSD, as well as from external hard drives and SD cards.

What Ritridata supports for this scenario: recovering deleted source code files from Windows HDD and SSD; files from external hard drives and USB drives; deep scan mode that searches sector-by-sector for deleted file signatures; file preview before recovery so you can confirm the correct version.

What Ritridata does not cover: Mac file systems; RAID or NAS; Linux; cloud-hosted databases.

Recovery workflow:

Step 1 — Download Ritridata to a different drive than the one being scanned (USB drive or secondary internal drive). Select the affected drive or folder location to scan.

Step 2 — Run a deep scan. Deep scan mode searches sector-by-sector and typically finds files that a quick scan misses — use it when the files have been deleted for more than a few minutes.

Step 3 — Filter results by file extension (.js, .ts, .py, etc.), preview files to confirm they contain the correct version of your code, and restore them to a separate drive — never to the same drive being scanned.

Part 9. Prevention — How to Protect Your Work Going Forward

The most reliable protection against Cursor agent deletions is a short commit before every agent session. A "WIP" commit costs ten seconds and gives you a verified restore point that no bug can touch.

Practical prevention steps:

• Commit to Git frequently — make a "WIP" or "pre-agent" commit before every Cursor agent session, even during fast iteration
• Use a snapshot tool like mrq — mrq auto-captures every change in real time and maintains a browsable history outside of Git
• Add Cursor project rules that explicitly prohibit destructive file operations without a confirmation prompt — place these in .cursorrules at the project root
• Enable auto-backup to an external drive or cloud folder (OneDrive, Google Drive, or Backblaze) so a second copy always exists
• Review diffs before accepting — treat Cursor Agent mode the way you would treat a code reviewer with full edit access: read the diff before clicking "Accept All"

🗣️ forum.cursor.com user: "I got used to Cursor deleting my files when using their checkpoints — commit to git often, so you have a saved version remote."

These habits require almost no extra time per session and eliminate the scenarios where Checkpoint and Local History recovery are the only options.

Part 10. FAQ

Q1: Does Cursor send deleted files to the Recycle Bin?

Not always. Cursor typically removes files directly from disk, bypassing the Recycle Bin. Always check the Recycle Bin first, but if the files are not there, proceed to the recovery steps in this guide — the file data may still be on disk even if the Recycle Bin is empty.

Q2: How do I access Cursor's Local History?

Press Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (Mac) and type "Local History: Find Entry to Restore." File names in Local History are aliased and URL-encoded — open each entry to identify the right version by its content rather than its displayed name.

Q3: What are Cursor Checkpoints and how long do they last?

Checkpoints are automatic snapshots that Cursor creates at the start of each Composer prompt. They are stored in memory during the session and typically do not persist after you restart Cursor. Use them immediately if Cursor is still open from the session when the deletion occurred.

Q4: Can I recover files if Cursor was already closed after the deletion?

Possibly. Local History persists across restarts and may contain the file if it was ever opened in the editor. The CursorRecovery tool can extract additional history from Cursor's SQLite database. If those options return nothing, data recovery software can scan the raw disk — success depends on how much new data has been written to the drive since the deletion.

Q5: What is the CursorRecovery GitHub tool?

CursorRecovery is a Python utility by bbostock that extracts file version history from the Cursor IDE's local VSCode SQLite database. It decodes aliased file names and maps recovered versions back to their original paths, making it practical to recover many files at once without manually identifying each aliased entry.

Q6: Why does pressing Undo delete my files in Cursor?

This is a documented bug in Cursor 1.3. In some cases, pressing Undo on a file that the agent had edited empties or deletes the file instead of restoring the previous version. Check forum.cursor.com for the current status and whether a patch has been released.

Q7: Can data recovery software recover source code files?

Yes, in many cases. Source code files are standard text files with common extensions. Data recovery software can find them on Windows drives using sector-level scanning as long as the storage has not been heavily overwritten since the deletion occurred.

Q8: What if Cursor deleted a database file (.sqlite, .db)?

Data recovery software may recover the raw database file if disk sectors have not been overwritten. After recovering the file, use a database repair tool to attempt to fix any internal corruption that may have occurred. Note that partial overwrites can corrupt database integrity even if the file is recovered.

References

1. Cursor Community Forum — Cursor deleted my file
2. Cursor Community Forum — Critical Bug in Cursor 1.3 – File Loss on Undo
3. mrq Blog — AI Deleted My Files: How to Recover
4. GitHub — bbostock/CursorRecovery
5. Dre Dyson — Fix Cursor IDE File Deletion Disaster