For some reason, Cursor tries to auto-update everytime I close the app. While in theory it should work fine, I often close the app a few seconds before shutting down my laptop.
This means next time I try to use Cursor, it is “uninstalled”. I need to remember where the heck it stores it files, go to the “_” temp folder, move all files back into root folder (and wait for minutes until the ~19k files are moved - thanks NPM…).
Could you please either handle this better or behave as most apps which ASK THE USER before installing an update, or at least trigger the update when the app STARTS, not when it is CLOSING?
Steps to Reproduce
Open Cursor
Receive an update
Quit Cursor
Shutdown/restart windows right after close
Try to open Cursor (file not found, because it’s now in “_” folder
Expected Behavior
Any of the following:
Ask before initiating an update, that way the user knows it needs to wait (and inform when done)
Install updates when the app starts, not when it’s closed
Keep a lightweight exe in root folder so it can recover from crashed updates without manual intervention from user
Hey thanks for the detailed report and screenshots. I see the _ folder and the dialog about moving 19k files back. This is a known bug with the Windows auto-updater. If the system shuts down or restarts before the update finishes the install phase the old binary gets deleted and the new one does not install. That is why Cursor.exe is missing and files end up in the temp folder. The issue is known and tracked but I cannot give an ETA on the fix yet.
What you can do right now.
Restoration
Fully close Cursor including the tray icon.
Before a new install remove leftovers from the interrupted update. Delete the contents of the _ folder and the old install directory %LOCALAPPDATA%\Programs\cursor so the new installer does not hit broken files.
Settings and extensions stay in %APPDATA%\Cursor and %USERPROFILE%\.cursor. They do not get lost. Only the binary itself disappears.
To stop this from happening again
Turn off auto-update. Go to Cursor Settings > search for update.mode > set it to none. Update manually through the Help menu when it suits you.
Before restarting or shutting down Windows fully close Cursor and let the update finish.
If this is a work machine with antivirus or EDR add the install folder %LOCALAPPDATA%\Programs\cursor to exclusions so protection does not hold a file handle during the update.
Your ideas about asking before an update installing on startup or keeping a recovery exe are basically the right direction for the updater. Let me know if anything else breaks after reinstall.
Dean I see you’ve replied to several copies of this same bug report.
You guys need to fix this in a strategic way that doesn’t involve users doing it themselves.
Try registering a service in Windows that is scheduled to run on reboot (as a fallback) which also attempts to monitor the file-handle situation and automatically runs the installer when the file handles are freed up. The service is a way to catch any problems with the file handles being locked before reboots or system crashes.
I suspect no sufficient strategy was dreamed up yet, so there’s my solution. The team is free to use it as a prompt. Or you could simply tell an AI that you need an atomic update solution on Windows and it should navigate the issue.
Also, @Bruno_Lima 's suggestions are quite reasonable UX architecture
Ask before initiating an update, that way the user knows it needs to wait (and inform when done)
Install updates when the app starts, not when it’s closed
Keep a lightweight exe in root folder so it can recover from crashed updates without manual intervention from user
Yeah, that’s right. This setting lives in the editor settings Settings UI or settings.json, not in the Plan panel in the Agents window. You found the right place.
start is a good choice. Cursor only checks for updates on launch and doesn’t run background checks, so the update won’t kick off when you close the app anymore. If you want full manual control, you can set it to manual and update whenever you want.
Let me know if anything still behaves weird after switching the mode.
@deanrie Hey Dean, this is incredibly frustrating… this happens nearly every other day with the amount of frequent updates to the Cursor app. It has literally happened multiple times a week for months on end…why is this still persisting?
And if it such a known bug in the community, why continue to release so many minor patch updates without addressing this internally?
Can the team please surface this as a priority ticket, it is a severe detriment on quality of life usage and blocker on productivity and often times disrupts agents in the middle of a push or merge.
Hey Calvin. I get it, hitting this a few times a week is really exhausting, especially when it kills the agent in the middle of a push or merge.
This bug is known. I can’t share an ETA yet, but if you want to stop it right now, turn off auto-update. That’s the most reliable way to avoid the loop until there’s a fix.
Cursor Settings > search for update.mode > set it to none (or manual if you want to update yourself via the Help menu when it’s convenient). After that, Cursor won’t try to update on close, so an interrupted shutdown won’t break the install.
If Cursor is already broken, fully quit it (including the tray icon), delete the contents of the _ folder and the old directory %LOCALAPPDATA%\Programs\cursor, then install the latest version from Cursor · Download. Your settings and extensions are in %APPDATA%\Cursor and %USERPROFILE%\.cursor and won’t be lost. Only the binary gets replaced.
If this is a work machine with antivirus or EDR, add %LOCALAPPDATA%\Programs\cursor to exclusions so the protection doesn’t hold a file handle during updates.
Let me know if anything still breaks after switching to none or manual.
