Windows inno_updater: Access is denied (os error 5) deleting resources — reproduced 3 times

[kakabanga]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Windows updater deletes the existing install, then fails to delete resources with Access is denied. (os error 5). Same failure on three consecutive updates (13 Aug, 15 Aug, 19 Aug 2026).

Latest update (3.16.17 → 3.16.29) still hit it. Cursor did eventually launch after this latest one, but the inno_updater log ends at the error, and a leftover CodeSetup-stable-3.16.29.exe (~194 MB) remains in %TEMP%.

Custom install path: D:\Software\Cursor\cursor (user setup, not %LOCALAPPDATA%\Programs\cursor).

Related:

[Bug] Windows auto-update constantly "uninstalling" Cursor

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug 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…)…

Cursor uninstalled itself and didn’t install afterwards continued

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug This still happens, even on cursor 3+ Had it happen today again. Steps to Reproduce How should I know Operating System Windows 10/11 Version Information Cursor is gone, nothing to check. Last installer I downloaded was CursorUserSetup-x64-3.0.12.exe Does this stop you from using Cursor Sometimes - I can sometimes use Cursor

Steps to Reproduce

1. Run Cursor on Windows from a custom install path
2. Leave it running (agent loops / terminals / MCP)
3. Allow auto-update to download in the background
4. Quit so the staged Inno updater applies (do_update: …Cursor.exe, _)
5. Updater waits for Cursor.exe, deletes files, then fails on resources

Expected Behavior

Do not delete the working install until the new files are in place. If resources is locked (node.exe / rg.exe / MCP children), abort and roll back.

Operating System

Windows 10/11

Version Information

Version: 3.16.29 (user setup)
VS Code: 1.128.0
Commit: 6246455961129c32969845e00aa25d87ae926ec0
Install: D:\Software\Cursor\cursor
Channel: win32-x64-user / stable
Inno Updater v0.14.0

Additional Information

main.log (3.16.17 session, local time UTC+3):
2026-08-19 04:58:18.717 [info] update#setState checking for updates
2026-08-19 11:15:31.373 [info] update#setState downloading
2026-08-19 11:16:19.761 [info] update#setState downloaded
2026-08-19 11:16:20.504 [info] update#setState updating
2026-08-19 11:21:23.502 [info] update#setState ready
2026-08-19 11:39:33.182 [info] update#recheckOutdatedUpdateOnResume

cursor-inno-updater-1787142724.log (19 Aug, timestamps UTC):
Aug 19 12:32:04.677 INFO Starting: D:\Software\Cursor\cursor\Cursor.exe, true, Updating Cursor…
Aug 19 12:32:04.692 INFO Cursor.exe is running, wait a bit
… (14 wait attempts) …
Aug 19 12:32:11.501 INFO Cursor.exe is not running
Aug 19 12:32:11.521 INFO Inno Updater v0.14.0
Aug 19 12:32:11.549 INFO do_update: “D:\Software\Cursor\cursor\Cursor.exe”, _
Aug 19 12:32:20.358 INFO All files deleted
Aug 19 12:32:20.359 INFO Delete directory recursively: “…\resources” (attempt 1)
…
Aug 19 12:32:41.625 INFO Delete directory recursively: “…\resources” (attempt 11)
Aug 19 12:32:48.640 ERRO Access is denied. (os error 5)

Same error in:
%TEMP%\cursor-inno-updater-1786629358.log (13 Aug)
%TEMP%\cursor-inno-updater-1786785294.log (15 Aug)

Workaround already applied:
update.mode = manual
update.enableWindowsBackgroundUpdates = false

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[deanrie]

Hey, thanks for the detailed report and logs, the signature here is pretty clear. This is a known issue with the Windows updater that we’re tracking. The old install gets removed before the new files are in place, and if some process is holding the resources folder at that moment (bundled node.exe / rg.exe, an MCP server, or antivirus), the delete fails with Access is denied. (os error 5) and the install ends up in a broken state.

Your workaround with update.mode = manual and enableWindowsBackgroundUpdates disabled makes sense, I’d keep it like that for now.

To reduce the chance of hitting this during a manual update:

• Before updating, fully close Cursor and check Task Manager to make sure there are no leftover Cursor.exe, node.exe, rg.exe, or MCP server processes running from the install directory D:\Software\Cursor\cursor. If you see any, end them manually.
• As an alternative, reboot your machine before applying the update so there are definitely no orphaned processes holding files.
• If antivirus is active, it’s worth checking whether it’s holding a handle on the folder during the swap.

The leftover CodeSetup-stable-*.exe in %TEMP% after a failed update is safe to delete manually.

I can’t share a timeline yet, but I’ll post in the thread if there’s an update. Let me know if it happens again even after you’ve cleanly closed all processes.

[deanrie]

Hey @kakabanga, circling back to this thread. The Windows updater improvements shipped in the latest Cursor release and fix the behavior you described. The old install now stays in place until the new files are ready, and if something is still holding the resources folder, the update rolls back instead of leaving a broken install. This matches what you outlined in Expected Behavior (journal + backup + rollback).

Since you switched update.mode to manual, you’ll need to run the update manually, or grab the latest installer from Cursor · Download. Before you do, I’d still recommend fully closing Cursor, just to be safe for this transition.

Let me know if you still see Access is denied (os error 5) after updating to the latest version, especially on updates from that version onward. Thanks again for the detailed logs.