In-app Update restarts without unsaved-file prompt and discards dirty editor buffers

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

If I have unsaved edits in an open file (dirty tab / white-dot indicator) and I click the IDE’s in-app Update prompt, Cursor does not warn that files are unsaved. It proceeds with the update and restarts.

After the update, when Cursor reopens the same project, those unsaved edits are gone. The file on disk is the last explicitly saved version.

This is data loss. An update restart should either:

  1. Prompt to Save / Don’t Save / Cancel before restarting, or
  2. Persist dirty buffers via Hot Exit (Backups/) and restore them after the update.

Neither happens.

This is related to, but distinct from, known reports where an update restart rewrites files, refreshes mtimes, or truncates files to 0 bytes from pending Agent diffs. This path is user-typed dirty buffers disappearing, not disk files getting rewritten.

Steps to Reproduce

  1. Open a project in Cursor.
  2. Edit a file and do not save it (tab shows the unsaved / white-dot indicator).
  3. When the in-app Update prompt appears, click Update.
  4. Observe: no “unsaved files” / Save — Don’t Save — Cancel dialog.
  5. After Cursor restarts and reopens the project, open the same file.
  6. The editor shows the last saved on-disk contents. The unsaved edits are gone.

Expected Behavior

Cursor should prompt that there are unsaved changes and let me save or cancel the update.

If the update is treated as a Hot Exit restart (files.hotExit default onExit), dirty buffers should be written to the Backups directory and restored on next launch.

Losing dirty editor buffers across an in-app update is not acceptable.

Operating System

Windows 10/11 (Windows_NT x64 10.0.26200). Cursor IDE is a Windows user-setup install. The workspace is a remote Linux host (Ubuntu 24.04.4 LTS aarch64, Radxa Rock 5B). The in-app Update that discarded unsaved buffers ran on the Windows IDE.

Version Information

Copied from Help → About Cursor on the Windows IDE:

Version: 3.20.10 (user setup)
VS Code Extension API: 1.128.0
Commit: d6f462cdd0a6a6d1cff570daf980e671d0a63de0
Date: 2026-09-10T21:04:54.045Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

Remote workspace host: Linux aarch64, Ubuntu 24.04.4 LTS (Noble), kernel 6.1.0-1025-rockchip (Radxa Rock 5B).

For AI issues: which model did you use?

N/A — not an agent/model issue. The lost content was user-typed unsaved editor buffers.

For AI issues: add Request ID with privacy disabled

N/A — not an AI request. This is an in-app Update / editor Hot Exit restore issue.

Additional Information

The Update prompt was on the Windows IDE (user setup), not on the remote Linux host. After the update, Hot Exit backups were not restored. On the remote Linux host, ~/.config/Cursor/Backups did not exist / was empty. For this setup, dirty buffers would normally live on the Windows machine under %APPDATA%\Cursor\Backups.

files.hotExit was left at the default (onExit), which suppresses the quit save prompt and is supposed to restore dirty buffers instead. The Update path appears to skip a clean Hot Exit flush and/or wipe/lose the Backups directory across the version swap.

Workaround today: Save All (Ctrl+K S) before clicking Update; enable Auto Save; do not treat Update as a safe restart.

Setting files.hotExit to off would restore a save prompt on a normal quit, but it is unclear whether the updater uses a clean shutdown or kills the process. If it kills the process, even off will not prompt.

Please treat this as a shutdown/restart safety bug on the Update path, not as expected Hot Exit behavior.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @Sean_Ni,

Two quick clarifications: the missing “Save / Don’t Save” dialog on Update is expected. With files.hotExit at its default, Restart to Update does a normal quit that backs up your unsaved edits and restores them after relaunch, rather than prompting. If you’d rather get the dialog, set files.hotExit to off (the updater doesn’t hard-kill the process, so off will prompt). Also, since the Cursor window runs on Windows and the Rock 5B is just the Remote SSH host, your backups live on Windows at %APPDATA%\Cursor\Backups, not on the Rock 5B, so an empty folder there is expected.

To pin down whether edits are actually being lost on the Windows side: make an unsaved edit, then run Developer: Reload Window (survives?), then fully quit with File > Exit and reopen (survives?), and finally repeat before a Restart to Update. If it only disappears on the update step, run Developer: Open Logs Folder, attach main.log, and I’ll dig in.