Cursor updater blocks with "access is denied" error on Windows

Support Bug Reports
1

This is not acceptable product behaviour for a paid editor.

On Windows, Cursor’s auto-updater repeatedly pops a modal while I am working:

There was an error while Deleting a directory:
C:\Users\AppData\Local\Programs\cursor_bak\resources
Access is denied. (os error 5)
Please verify there are no Cursor processes still executing.

Retry does nothing. Cancel dismisses it until the next update, then it comes back. This has happened to me on multiple days in a row (9, 12, and 14 Sep 2026). I am not doing anything unusual. I open Cursor, it tries to finish an update, and this dialog hijacks the screen.

The updater (inno_updater.exe) is trying to delete the old install copy under _bak while Cursor and its helper processes are still running. The lock is the bundled node.exe under resources\app\resources\helpers, including MCP servers Cursor itself spawned. The dialog tells me to make sure no Cursor processes are running — while I am inside Cursor, because Cursor launched the updater.

That is a broken update design:

Cursor starts child processes from files inside its own install folder.
Cursor then tries to delete that folder (or a backup of it) while those processes still hold the files.
The failure UI is a blocking error with Retry/Cancel, not a quiet retry in the background.
There is no recovery path that works without killing Cursor or renaming _bak by hand.
Workaround that actually works: rename _bak so the updater is no longer looking at a locked path, then Cancel. Deleting _bak in place fails for the same reason the updater fails.

Staff have already called this a known Windows updater issue, with leftover node.exe / MCP / rg.exe handles, and no ETA. “Fully quit Cursor first” is not a fix. Auto-update is supposed to work while people use the app. A known bug that interrupts work on every update, with the only advice being “close everything and hope,” is not an acceptable shipping state.

Please treat this as a P1 Windows update bug: stop showing a blocking error for a cleanup step, don’t delete files that Cursor’s own children still have open, and don’t leave _bak in a state that pops this dialog again on the next launch.

2

Hey, thanks for the detailed write-up, it really helps. One important note: what you’re describing is different from the original issue in this thread. In the OP’s case, the old updater removed a working install and left it broken. In your case, the new updater keeps the install intact (it’s still working), but it fails on the cleanup step for the backup folder cursor_bak\resources. That folder is being held by the bundled node.exe or MCP helpers, and instead of retrying quietly it shows a blocking modal with Access is denied (os error 5). A blocking dialog on every update is definitely not the expected behavior.

To report this to the team as a separate issue (this is a different symptom than the thread header), can you confirm a couple of things:

  • Your exact Cursor version (Help > About). I want to confirm you’re on the latest 3.19.x.
  • After you close the modal, does Cursor itself launch and work normally? Based on what you wrote it does, but I want to lock that in.

For now, your workaround (rename _bak, then click Cancel) is fine, you can keep using it. As an extra step, before updating, fully quit Cursor and check Task Manager to make sure there are no node.exe or rg.exe or MCP processes still running from the install folder, or reboot before applying the update. That way the old _bak can be removed without any handles.

I’ll pass this to the team as a separate issue with the new updater. I can’t share an ETA, but I’ll reply if there’s an update. If you want, you can also start a separate thread just for this _bak modal so it’s easier to track, but it’s not required.

3

Thanks — that distinction is correct.

This is not the “updater bricks the install” case. Cursor still launches and works after I close the modal. The failure is only the cleanup step for cursor_bak\resources. Instead of retrying quietly, the new updater shows a blocking Access is denied (os error 5) dialog.

Version: Cursor 3.20.21 (stable), commit f09fca384ceca23f7bf21f9c23655b162641d740, 2026-09-13. That is newer than 3.19.x.

After closing the modal: yes. Cursor itself is fine. I click Cancel (Retry does nothing while the helpers still hold the files), keep working, and the same dialog comes back on the next update.

I’d appreciate it if you could pass this to the team and open a separate thread for the _bak modal so it’s easier to track.

The “fully quit / kill node.exe and MCP / reboot before updating” steps are a workaround, not a fix. Auto-update is firing while I am already in Cursor, which is how this dialog shows up. A blocking error on a leftover backup folder, with a working install, should not be the update UX. Thank you!

4

Thanks for confirming the details. That makes the picture complete.

Confirming the split: what you’re seeing on 3.20.21 is a separate symptom from the title of this thread. Your install is fine and Cursor works, only the cleanup step for the backup folder cursor_bak\resources is failing. Instead of a silent retry, the new updater shows a blocking modal Access is denied (os error 5), and it comes back on the next update. A blocking dialog during cleanup of a working install is definitely not the behavior we want.

I’m passing this to the team as a separate issue for the new updater. I can’t give an ETA, but I’ll reply in the thread if there’s an update.

Good idea to make a separate thread for the _bak modal. Please create it (or I can split it out) so it’s easier to track separately from the original problem. Include the version 3.20.21, commit f09fca384..., and a screenshot of the modal if you have one.

Your workaround (rename _bak, then click Cancel) works, so feel free to keep using it for now. As an extra step: before updating, fully close Cursor and check in Task Manager that there are no node.exe, rg.exe, or MCP processes left from the install folder (or reboot the machine). Then _bak should delete without locked handles. I know this isn’t a fix, but it should prevent the modal during the update.

Let me know if the modal shows up even after you’ve cleanly closed all processes.

6

I’ve been having this problem. The cause was in fact not cursor itself, but VSCODE. Apparently cursor’s bin folder (which is within resources) is in the PATH, so if a program is keeping an eye on PATH endpoints (say for autocomplete) then it’s gonna get locked. It’s probably best not to move directories that contain PATH elements, maybe copy them instead? Or perhaps move bin up the tree a bit so it can be isolated. Stuff probably IS gonna look at the PATH.

Let me know if you need diagnostics, I’ll try to replicate the problem.

8

Hey, thanks for the detailed diagnosis. This is a really valuable piece of the puzzle. What you’re describing matches what we’re seeing. Cursor’s bin folder lives inside resources and ends up on PATH, and apps that watch PATH endpoints (VS Code, autocomplete tools, some shells) can keep an open handle to that folder. Because of that, cleanup of the old _bak fails with Access is denied (os error 5).

I’ve shared this with the team along with the thread. I also included the “copy instead of move” idea and the option to move bin higher up the directory tree as possible approaches. I can’t share an ETA, but I’ll reply here if there’s an update.

Practical steps for now: before you let Cursor update, close VS Code and any other tools that might be monitoring PATH. Also, a working workaround from the thread is to rename _bak, then click Cancel. It’s not a fix, but it gets rid of the modal.

If you can reproduce it, I’d really appreciate output from Process Explorer using Find Handle or DLL for the locked folder cursor_bak\resources. That will show exactly which process is holding the handle and confirm the PATH angle. Share it here if you can.

9

image

Here we go. It only happened after I built my rust project using a build script from within vs code’s Terminal tab. It may yet be related to the build script - restarting vs code clears the lock, as expected, but rebuilding my rust project hasn’t reacquired it, possibly because the project was already mostly built (that’s only a guess). I think you’re probably stuck with assuming that there will be badly-behaved actors looking at PATH, so you can’t move it. I see there’s not a whole lot in that bin folder, I suspect the cursor.cmd is what counts. If that’s the only one that’s needed then I’d move it. Though then you’re gonna have to deal with shuffling everyone’s PATH variables, sigh. Maybe make a resources_new and put the new stuff there, sans PATH, and leave our orphan where it is :stuck_out_tongue:

I’ll experiment some more and post what I find. Feel free to contact me here or directly and I’ll help where I can.

  • Andrew
10

Hey Andrew, this is exactly the missing piece, thanks. The screenshot shows the handle on resources\app\bin is held by Code.exe, so the PATH version is confirmed: VS Code (or a tool watching PATH) keeps an open handle on bin inside resources, and that’s why cleanup of the old _bak fails with Access is denied (os error 5).

Interesting note: the lock appeared after building a Rust project from the VS Code terminal, and restarting VS Code clears it. I passed this to the team along with your ideas about isolating bin and cursor.cmd, plus the option of using a separate resources_new without PATH. I can’t give an ETA, but if there’s an update I’ll post it here.

If you keep experimenting, it’d be especially helpful to confirm whether the handle stays after closing just the terminal tab, not the whole VS Code, and whether the lock reproduces on a clean rebuild after cargo clean. Share what you find.

For now the workaround is still the same: before updating, close VS Code and any other tools that watch PATH, or rename _bak and click Cancel.

11

Just for completeness: I do use VS Code, but no Tool was running in the background. I checked that again. For now, I am having Cursor itself fix the problem by renaming _bak and then deleting it.

12

Thanks for following up, that’s a helpful detail.

One important thing to clarify: even without any extra background tools, VS Code itself can keep an open handle on the bin folder inside resources, because it ends up in PATH. That’s exactly what Process Explorer confirmed earlier in the thread. The handle on resources\app\bin was held by Code.exe. So it’s enough for VS Code to simply be open, especially after using its integrated terminal. A separate watcher isn’t required. Because of that, cleanup of the old _bak fails with Access is denied (os error 5).

Your approach, let Cursor rename _bak and then delete it, works fine, so feel free to use it. As an extra safety step: before updating, fully close VS Code, or at least restart it if you recently built something in its terminal. That releases the handle on bin, and _bak deletes without showing the modal.

We’re tracking this issue. I can’t share an ETA yet, but I’ll reply in the thread when there’s an update. If the modal still shows up even after VS Code is fully closed and there are no processes left from the install folder, let me know, that would be an important signal.