Cursor.exe reverts working tree files without clicking Restore Checkpoint

Support Bug Reports
1

Title: Cursor.exe reverts working tree files without clicking Restore Checkpoint

Cursor.exe is writing files back to an older chat checkpoint on its own. I never clicked Restore Checkpoint.

Environment:

  • OS: Windows 11
  • Cursor version: [paste Help → About]
  • Request ID: [paste from this chat]

What happens:
While agents edit the repo, Cursor.exe rewrites the working tree:

  • Modified tracked files return to the last committed content
  • New untracked files are deleted or truncated to 0 bytes
  • git reflog shows no reset/checkout; commits already made are kept

Evidence (Windows Security log, Event ID 4663, Process Name = Cursor.exe):

  • 2026-09-26 19:39:39 — Cursor.exe wrote backend/apps/statistics/api/views/evolution.py (content reverted). The file watcher logged the revert at 19:39:41.
  • 2026-09-26 19:47:17 — Cursor.exe truncated three canary files to empty in the same second:
    TRAMPA-CANARIO.txt
    backend/apps/statistics/api/views/TRAMPA-CANARIO.txt
    frontend/src/views/TRAMPA-CANARIO.txt
    Same pattern earlier that day (~16:45, ~17:10, ~19:22), always while background agents were editing.

Docs say checkpoints restore only when the user clicks Restore Checkpoint. There is no setting to disable this. Please treat the unsolicited restore as a bug, especially when several agents touch the same files.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

5

==============================================

QUIEN TOCO LOS ARCHIVOS DE SENSEI
Ventana: 26/09/2026 16:30 a 20:00

Leyendo el registro de Seguridad (puede tardar un minuto si hay muchos eventos)…
Eventos 4663 revisados: 150
Eventos sobre el repo SENSEIDATAPREVENTION_V2: 146

PROCESO: C:\Users\hsoriano\AppData\Local\Programs\Git\mingw64\bin\git.exe - toco 24 archivos (95 eventos)
Primeras rutas tocadas:
19:55:26 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2.git\index.lock
19:54:25 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2.git\index.lock
19:54:09 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2.git\gk
19:54:09 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2.git\gk\config.lock
19:54:09 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2.git\gk\config.lock

PROCESO: C:\Users\hsoriano\AppData\Local\Programs\cursor\Cursor.exe - toco 9 archivos (41 eventos)
Primeras rutas tocadas:
19:47:17 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\frontend\src\views\TRAMPA-CANARIO.txt
19:47:17 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\backend\apps\statistics\api\views\TRAMPA-CANARIO.txt
19:47:17 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\TRAMPA-CANARIO.txt
19:39:39 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\backend\apps\statistics\api\views\evolution.py
19:39:39 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\backend\apps\statistics\api\views\evolution.py

PROCESO: C:\Windows\System32\dllhost.exe - toco 2 archivos (5 eventos)
Primeras rutas tocadas:
19:44:23 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\backend.pytest_cache\v\cache\nodeids
19:44:23 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\backend.pytest_cache\v\cache\nodeids
19:44:23 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\backend.pytest_cache\v\cache\nodeids
19:42:26 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\frontend\vite.config.js.timestamp-1790469745522-169f536b279a2.mjs
19:42:25 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\frontend\vite.config.js.timestamp-1790469745522-169f536b279a2.mjs

PROCESO: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe - toco 2 archivos (5 eventos)
Primeras rutas tocadas:
19:51:37 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\frontend\src\utils_trampa_repro_
19:33:19 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\TRAMPA-CANARIO.txt
19:33:19 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\TRAMPA-CANARIO.txt
19:33:19 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\TRAMPA-CANARIO.txt
19:31:19 C:\Users\hsoriano\Documents\GitHub\SENSEIDATAPREVENTION_V2\TRAMPA-CANARIO.txt

El PROCESO con mas eventos es el principal sospechoso.
Si es OneDrive.exe, un antivirus o un sincronizador, ahi esta la causa.

Reporte completo guardado en: C:\Users\hsoriano\OneDrive - AUDIOAUTO S.A. - TRACKLINK\Escritorio\ver-culpable-resultado.txt

Presiona ENTER para cerrar:

El culpable es Cursor, el programa donde estamos chateando. No es OneDrive, ni un antivirus, ni la otra PC.

Las horas coinciden al segundo:

  • 19:39:39 — Cursor.exe escribió evolution.py (y el resto de las vistas). Un segundo después el vigilante vio la reversión.
  • 19:47:17 — Cursor.exe vació los tres archivos canario, los tres a la vez.

git.exe solo tocó cosas internas de git (el índice y un lock). powershell.exe fue la trampa. dllhost.exe es Windows mirando cachés. Ninguno de esos revirtió tu código.

Cursor guarda un checkpoint del chat. Cuando un agente en segundo plano termina, Cursor reescribe el disco con la foto anterior del chat: lo modificado vuelve al contenido de git, lo nuevo se borra o queda vacío. No usa git reset, por eso los commits (32aeb75 y 3bbb26b) sobrevivieron.

Para seguir seguro: commit apenas termine cada bloque. Si Cursor vuelve a pisar el disco, el trabajo sigue en git y se recupera. La trampa sigue armada por si pasa otra vez.

8

Hey @Henry_Daniel_Soriano, this isn’t OneDrive, an antivirus, your other PC, or a git op (your clean reflog and surviving commits confirm that). It’s Cursor’s own file-restore path writing to disk, and it’s not intended behavior. Since it never touches git, committing after each block (as you’re doing) keeps everything recoverable.

To lower the chance of it firing: avoid running agents in parallel on the same files (give each its own set), and hit Keep All in the review bar before starting a new agent so there’s no leftover diff state to restore.

One thing that would pin the exact cause if you can: open a reverted file, expand the Timeline section at the bottom of the Explorer, and tell me the exact label on the entry at the revert time (for example “Undo Create Diff”, “File Saved”, or an extension name).

We’ve let the team know and this is an issue we’re tracking. I’ll post here when there’s an update.