Failed to install Cursor update. Updates may fail due to anti-virus software and/or runaway processes. Please try restarting your machine before attempting to update again.
The inno-updater log shows it repeatedly trying to move resources → _bak\resources. Then it fails with Backup phase failed, reverting to the previous install: Access is denied. (os error 5) and stays on the old version. This happens with both background updates and “Restart to Update”.
Cause: VS Code’s extension-host processes hold open directory handles on two Cursor folders that the Cursor installer adds to the user PATH. VS Code runs one of these processes per window (Code.exe --type=utility --utility-sub type=node.mojom.NodeService). The two folders:
Windows won’t rename a folder while something inside it is open, so moving resources fails. Once VS Code is closed, the update succeeds.
Before the swap, the updater only checks whether Cursor.exe is running. It then fails, and the dialog blames antivirus instead of naming the process that holds the folder.
Steps to Reproduce
Install Cursor with the Windows user installer and keep “Add to PATH” checked. This puts resources\app\bin and
resources\app\codeBin on the user PATH.
Install VS Code (user setup) and keep at least one window open.
Let Cursor download an update, then click Restart to Update, or quit Cursor so the staged background update runs.
The update fails with the dialog above and Cursor stays on the old version.
Close all VS Code windows and update again. It succeeds.
Note: I haven’t isolated which VS Code component or extension opens the handles.
Expected Behavior
The update succeeds even when another app has Cursor’s PATH folders open.
If it can’t, the error names the blocking process instead of a generic antivirus message. For example: “Visual Studio Code(Code.exe) is using files in the Cursor folder. Close it and click Retry.”
Failed background updates are shown to the user instead of failing silently.
Operating System
Windows 10/11
Version Information
Cursor: 3.22.7 , updating to 3.23.23
Install type: user setup, %LOCALAPPDATA%\Programs\cursor
Updater: Inno Updater v0.16.0
VS Code running at the same time: 1.140.0
Additional Information
Log excerpt (%TEMP%\cursor-inno-updater-*.log):
INFO Checking for running Cursor.exe processes… (attempt 1)
INFO Cursor.exe is not running
INFO Update journal: BackingUp
INFO Move: “…\cursor\resources” → “…\cursor_bak\resources” (attempt 1)
… (repeated retries)
ERRO Backup phase failed, reverting to the previous install: Access is denied. (os error 5)
ERRO Access is denied. (os error 5)
Hey, thanks for the detailed report and for tracking down VS Code as the process keeping Cursor’s PATH folders open.
This is a known issue we’re tracking, and I’ve shared your findings with the team. You’ve identified the cause: when another process has something open inside Cursor’s install folder, the updater can’t move resources. It fails with os error 5 and rolls back to the current version.
For now, the workaround is:
Close all VS Code windows before clicking “Restart to Update.”
If the error dialog is already open, close VS Code and click “Retry,” not “Cancel.”
You also suggested that VS Code itself may be holding the handles, rather than a specific extension. If you have a minute, could you check whether terminal suggestions are involved?
In VS Code, open Settings with Ctrl+,, find terminal.integrated.suggest.enabled, and turn it off.
Run “Developer: Reload Window” from Ctrl+Shift+P in every open VS Code window.
In Process Explorer, search for cursor\resources again and check whether Code.exe still has handles on resources\app\bin or resources\app\codeBin.
If the handles disappear after that, please let us know. That would help us narrow this down. I’ve also shared your feedback about the error dialog blaming antivirus instead of naming the blocking process, and about background updates failing without a clear notification.
I can’t give you an ETA for a fix yet, but I’ll reply in this thread when there’s an update.
Thanks for following up. I ran the test, and disabling terminal suggestions does not release the handles.
Test
Set "terminal.integrated.suggest.enabled": false in VS Code user settings.
Ran Developer: Reload Window in every VS Code window and opened a terminal.
Checked handles on Cursor’s install folder again.
Result
resources\app\bin and resources\app\codeBin are still held, now by the new VS Code helper processes (Code.exe --type=utility --utility-sub-type=node.mojom.NodeService, one per window) that started after the reload.
Why
The handles come from VS Code’s built-in terminal-suggest extension (extensions\terminal-suggest\dist\terminalSuggestMain.js,
VS Code 1.140.0). Its activate() splits PATH and creates a file watcher on every PATH folder that exists, roughly:
for (const dir of PATH.split(path.delimiter)) {
if (!(await fs.promises.stat(dir)).isDirectory()) continue;
const w = vscode.workspace.createFileSystemWatcher(new vscode.RelativePattern(vscode.Uri.file(dir), '*'));
// onDidCreate / onDidChange / onDidDelete -> refresh executable cache
}
This runs unconditionally and never checks terminal.integrated.suggest.enabled. The extension activates on onTerminalShellIntegration:*, so opening any terminal in VS Code creates the watchers. Because Cursor adds resources\app\bin
and resources\app\codeBin to PATH, VS Code watches them, and Windows then refuses to move resources.
This affects more than VS Code
Any app that watches PATH folders will break Cursor updates the same way.
For now, closing VS Code before “Restart to Update” works reliably.
Thanks, this is exactly what needed to be checked, and the result matters.
So it looks like turning off terminal.integrated.suggest.enabled does not release the handles, because terminal-suggest unconditionally sets watchers on PATH folders regardless of that setting, and they get created again when a terminal is opened in a new window. I passed that clarification to the team. Your review of the extension code rules out the previous theory.
For now, the reliable workaround is still the same: fully close all VS Code windows before Restart to Update. If the error dialog is already open, close VS Code and click Retry, not Cancel. As you showed, turning off the setting does not help, so don’t rely on that.
I also noted your point that this can break updates for any app that watches PATH folders, not just VS Code.
I can’t give an ETA yet, but I’ll reply here when there’s an update.
In the latest versions, the Windows updater was changed. If it can’t replace the files, it now rolls back to the current version and Cursor keeps working, which you’ve already seen. Cursor also does a better job now of closing its background processes before updating. But that doesn’t change your case. If another app is holding Cursor PATH folders inside resources, the update still rolls back. So the issue still happens if VS Code is open.
I’ve passed this to the team as a separate issue along with your analysis: the PATH folders are inside resources, and the dialog points to antivirus but doesn’t show which process is actually holding the folder.
For now, the reliable workaround is still the same: close all VS Code windows before Restart to Update. If the error dialog is already open, close VS Code and click Retry.
If closing VS Code every time is annoying, you can try this instead. The watchers are created by the built-in extension itself, not by a setting, so:
In VS Code, open Extensions and search for @builtin terminal suggest.
Click Disable.
Run Developer: Reload Window in each open window, then open the terminal.
In Process Explorer, search again for cursor\resources.
I haven’t tested this myself on Windows, so let me know if the handles on resources\app\bin and codeBin disappear. For completeness, there’s also the option to remove those two folders from the user PATH, but then the cursor command won’t work in terminals.
There’s no ETA yet. I’ll post here when there’s another update.