Windows Update offered version 3.19.19. That version is not the public latest on the official Cursor download page, which still ships 3.19.13. Clicking Update restarted Cursor twice about 40 seconds apart. After restart the running app was still 3.19.13. New files were left in C:\Software\cursor_\ as 3.19.19. Windows Add/Remove Programs already showed DisplayVersion 3.19.19.
Cursor would not start until I overwrite-installed official 3.19.13 from the official download page at about 11:33 UTC+8. After that, the bottom-left Update button came back. I am not clicking it.
This looks like a failed Win32 UpdateSupervisor swap: restart happened, the underscore staging folder was not swapped into the install dir, and the update channel still serves 3.19.19.
Steps to Reproduce
Run Cursor 3.19.13 on Windows 11, install path C:\Software\cursor.
Click Update when offered. Logs show targetVersion=3.19.19, which is not the public latest (official download is 3.19.13).
Cursor restarts twice about 40 seconds apart (11:30:27 and 11:31:06 UTC+8). After restart, running Cursor.exe and product.json are still 3.19.13. C:\Software\cursor_\ contains 3.19.19. Windows Add/Remove Programs DisplayVersion is already 3.19.19.
Download official 3.19.13 from the official Cursor download page and overwrite-install (about 11:33 UTC+8).
Bottom-left Update button appears again. I did not click it.
Expected Behavior
The update channel should not serve a version that is not the public latest. After clicking Update, the running binary should actually become the new version, or the update should fail without rewriting the uninstall DisplayVersion and without leaving an underscore staging folder that keeps showing the Update button. Reinstalling official 3.19.13 should clear the Update prompt.
After the failed 3.19.19 update, Cursor would not start until I overwrite-installed official 3.19.13. The IDE only came back after that manual reinstall. Logs: Prepared/Armed targetVersion=3.19.19 at 11:25:10 UTC+8; restart acknowledged currentVersion=3.19.13 at 11:30:27. Update URL after restart still identified as 3.19.13, then immediately downloaded again. I will not click the Update button that reappeared.
On the version question first: 3.19.19 is the real next Cursor release. New versions roll out gradually through the in-app updater before the download page is updated, so the update button offering 3.19.19 while the website still shows 3.19.13 is expected and safe. It will keep being offered until you take it.
The update itself is failing to swap in, and the cursor is not starting afterward, is something we should dig into!
To help us pin down what happened on your machine, could you attach these files?
Press Win+R, type %TEMP% and press Enter.
Attach every file named cursor-inno-updater-*.log and the Setup Log 2026-09-09 #00N.txt files from that folder.
Press Win+R again, type %APPDATA%\Cursor\logs and press Enter, open the folder dated 2026-09-09 around 11:30, and attach main.log.
Also let us know whether C:\Software\cursor\_bak\ or a file named cursor-update.journal.json exists in C:\Software\cursor\.
When you are ready to try the update again, please close all Cursor windows first, and if it fails again, grab the same logs before reinstalling (a copy of the new version usually sits in C:\Software\cursor\_\Cursor.exe and can be launched directly). Thanks!
Hi Colin, thanks for the clarification on 3.19.19.
I attached one zip with:
cursor-inno-updater log
Setup Log 001
Setup Log 002
main.log from 20260909T101009 (covers 11:07 to 11:25)
Findings:
inno_updater v0.15.0 ran at 11:25:11 local (log time 03:25:11 UTC). It logged “Cursor.exe is not running”, then started moving the live install into _bak, including Cursor.exe. Moving resources failed after 11 attempts with Access Denied (os error 5).
Setup log 001 then tried to launch the install-dir Cursor.exe and got CreateProcess error 2 (file not found). That matches Cursor not starting: the exe had already been moved to _bak, but the swap never finished.
The _bak folder and cursor-update.journal.json are gone now (I overwrite-installed official 3.19.13 to get the app back). The underscore staging folder still contains 3.19.19.
I have not clicked Update again. I can retry after a full quit if you want.
Update on a second failure today, after a full quit and relaunch.
I fully quit Cursor and opened it again. The updater started the file swap. The install directory C:\Software\cursor looked almost empty: Cursor.exe and most binaries were gone from the root. They had been moved into _bak while the swap was still in phase backing_up (cursor-update.journal.json). The underscore staging folder was also present at that moment.
I then installed the official Windows User setup for 3.19.19 (CursorUserSetup-x64-3.19.19.exe) into the same path. After launch I got this dialog:
There was an error while Moving: “Cursor.exe”:
Access Denied. (os error 5)
Please verify there are no Cursor processes still executing.
I clicked Cancel (Retry would fail while Cursor.exe is still running).
New inno_updater log: cursor-inno-updater-1789032604.log
Time: 17:30 local / 09:30:04 UTC on Sep 10
inno_updater v0.15.0, silent = true
It logged “Cursor.exe is not running”, then started moving the live install into _bak, including Cursor.exe. Moving resources failed after 11 attempts with Access Denied (os error 5). Same pattern as Sep 9.
I deleted _bak. The underscore staging folder was already gone. I did not click Update in the app.
Current About Cursor (working now):
Version: 3.19.19 (user setup)
VS Code Extension API: 1.128.0
Commit: 6496ea8a068aebfcd21990e70ff522e9abf10c80
Date: 2026-09-08T16:25:33.352Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
OS: Windows_NT x64 10.0.26200
Install path: C:\Software\cursor
No _ folder, no _bak, no cursor-update.journal.json, Cursor.exe is present again.
Root cause looks unchanged: inno_updater thinks no Cursor.exe is running, starts moving the live binary into _bak, then hits os error 5 on a locked file, leaving the install dir mid-swap. I can attach the new inno_updater log as a zip if you want it.
We just merged some changes to make sure that upon upgrade failure, the existing install remains working. Of course, the end goal is that the upgrade works perfectly, and we’re continuing to work on this!
Follow-up: I found what was locking resources (os error 5).
Cursor writes resources\app\bin into the user PATH so the cursor CLI works. That folder lives inside the install resources directory. Any process that keeps a handle on it will block the whole resources move during inno_updater.
On this machine, Resource Monitor showed other VS Code-family editors holding resources after Cursor.exe had already exited. inno_updater only checks whether Cursor.exe is running, so it started the swap, moved Cursor.exe into _bak, then failed on resources. File Explorer can also hold the folder if that directory is open.
The lock is not unique to one fork:
CodeBuddy CN takes the lock immediately.
VS Code also takes the lock, but after a delay rather than immediately.
The lock is released as soon as those editors are fully quit. Uninstalling them is not required. After I closed VS Code and CodeBuddy CN, the handle on resources disappeared right away.
Two workarounds:
Remove Cursor’s resources\app\bin from the user PATH if you do not use the cursor command.
Before quitting Cursor for an update, fully quit every other VS Code-family editor first (VS Code itself, CodeBuddy, and similar forks), including tray icons. Then quit Cursor.
Hope this helps others who hit Access Denied on resources even after Cursor.exe is gone.
@Chandira_G If you still have VS Code or another VS Code-based editor installed, this may be the same lock. Please see my latest reply in this thread: Cursor puts resources\app\bin on the user PATH, other VS Code-family apps can hold that folder, and inno_updater then fails with Access Denied on resources. Closing those editors (not uninstalling) released the lock for me. Reinstall is only needed if the swap already moved Cursor.exe away.