# Cursor.exe reverts working tree files without clicking Restore Checkpoint **URL:** \ **Category:** Bug Reports\ **Tags:** checkpoints\ **Created:** [September 27, 2026, 6:58pm UTC](https://forum.cursor.com/t/cursor-exe-reverts-working-tree-files-without-clicking-restore-checkpoint/173146 "2026-09-27T18:58:59Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Henry\_Daniel\_Soriano](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/henry_daniel_soriano/32/122250_2.png) [@Henry\_Daniel\_Soriano](https://forum.cursor.com/u/Henry_Daniel_Soriano)\ **Post date:** [September 27, 2026, 6:59pm UTC](https://forum.cursor.com/t/cursor-exe-reverts-working-tree-files-without-clicking-restore-checkpoint/173146/1 "2026-09-27T18:59:00Z")
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. ---
**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\ **Post date:** [September 27, 2026, 6:59pm UTC](https://forum.cursor.com/t/cursor-exe-reverts-working-tree-files-without-clicking-restore-checkpoint/173146/2 "2026-09-27T18:59:11Z")
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](http://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 > > ```auto > 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! ---
**Author:** ![Henry\_Daniel\_Soriano](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/henry_daniel_soriano/32/122250_2.png) [@Henry\_Daniel\_Soriano](https://forum.cursor.com/u/Henry_Daniel_Soriano)\ **Post date:** [September 27, 2026, 7:02pm UTC](https://forum.cursor.com/t/cursor-exe-reverts-working-tree-files-without-clicking-restore-checkpoint/173146/5 "2026-09-27T19:02:12Z")
# ============================================== 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. ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [September 28, 2026, 8:49am UTC](https://forum.cursor.com/t/cursor-exe-reverts-working-tree-files-without-clicking-restore-checkpoint/173146/8 "2026-09-28T08:49:58Z")
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.