Cursor fails to update when Visual Studio Code is running.
The updater reports an error while moving the resources directory with Access denied (os error 5), even when no Cursor processes are running.
Steps to Reproduce
Open Visual Studio Code on Windows.
Open Cursor and start an available update.
Let Cursor restart and run the updater.
The update fails while moving the resources directory.
Close Visual Studio Code and retry the update. The update succeeds.
Expected Behavior
Cursor should be able to update successfully even when Visual Studio Code is running, since VS Code is a separate application and no Cursor processes are running.
Hey, thanks for the report, and especially for the clear before and after test with VS Code. That’s a really helpful datapoint.
This is a known issue we’re tracking. During the update, Windows refuses to move the resources folder inside Cursor’s install directory because some process is still holding a file open inside it. In your case, the updater detected that and left your current Cursor untouched, so retrying later worked.
The most interesting part is that closing VS Code is what made the difference. To figure out which exact process is holding the folder, could you try this on the next available update?
Keep VS Code open, start the update in Cursor, and let it restart.
When the dialog There was an error while Moving: "resources" appears, do NOT click Retry or Cancel yet.
Press Win+R, type resmon, press Enter to open Resource Monitor.
Go to the CPU tab, then expand the Associated Handles section.
In Search Handles, type cursor\resources and press Enter.
Write down or take a photo of all processes in the results. A screenshot is ideal.
Then click Retry in the updater dialog.
Also, please attach the updater log from the failed attempt. Paste %TEMP% into the File Explorer address bar and grab cursor-inno-updater-1789177664.log and any other cursor-inno-updater-*.log files from the same day.
Two quick questions: which folder did you have open in VS Code at the time, and what antivirus or security software is installed on this PC?
Once you’ve collected that, send it here and we’ll dig in.
Great job with Process Explorer, that’s exactly the datapoint we were missing. Thanks for seeing it through.
The picture is clear now. Code.exe (VS Code) had an open handle on D:\software\cursor\resources\app\bin, a folder inside Cursor’s install directory. While that handle is open, Windows refuses to move resources to _bak during the update step, which leads to Access is denied (os error 5). As soon as VS Code closes, the handle is released and the retry succeeds. The logs confirm this. The updater made 11 attempts, then rolled back to the previous install, which is why Cursor stayed usable.
Most likely the handle is coming from the integrated terminal in VS Code, where the PATH or environment included Cursor’s resources\app\bin path, for example after installing the cursor command into PATH. A terminal or process launched from that directory is what keeps the folder locked.
For now, the practical workaround is to fully close VS Code, including any integrated terminals, before updating Cursor. You already found that, so this shouldn’t block you before an update.
I’ve passed this to the team as a confirmed datapoint. Your debugging should really help narrow down the root cause. If there’s an update on this, I’ll reply here.
