Auto-update fails and bricks the install when an orphaned child MCP process locks the install directory (Windows)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Windows, the auto-updater can leave Cursor in a broken, unlaunchable state if a child MCP server process is still running under the install directory when the update runs.

Cursor spawns stdio MCP servers (from a workspace .cursor/mcp.json) as child processes and runs them on its OWN bundled node.exe inside ...\cursor\resources\. On exit, Cursor does not terminate these children, so the MCP server is orphaned and keeps that directory locked.

When the updater then runs, it deletes the old top-level Cursor.exe and extracts the new build into a _\ staging folder BEFORE it tries to delete the old resources\ folder. That delete fails on the locked file:

There was an error while Deleting a directory: “…\cursor\resources”: Access is denied. (os error 5) Please verify there are no Cursor processes still executing.

Because the transaction has no rollback, it aborts mid-way, leaving: no top-level Cursor.exe, a stale locked resources\ folder, the new build stranded in _\, and the uninstall registry DisplayIcon pointing at the now-missing exe. The next launch/update attempt fails with:

Unable to execute file: …\cursor\Cursor.exe — CreateProcess failed; code 2. The system cannot find the file specified.

Recovery requires manually killing the orphaned process and re-running the full installer. This has now happened on two consecutive updates.

Steps to Reproduce

  1. Open a workspace containing a .cursor/mcp.json that launches a stdio MCP server via npx, e.g.:
    { "mcpServers": { "example": { "command": "npx.cmd", "args": ["--yes", "@some/mcp-server@latest"] } } }
  2. Let Cursor start the MCP server — it runs as a child node.exe using Cursor’s bundled node under ...\cursor\resources\app\resources\helpers\node.exe.
  3. Close Cursor. The child MCP node.exe is orphaned and keeps running, holding ...\cursor\resources\ open.
    (Verify in PowerShell: Get-CimInstance Win32_Process | ? { $_.ExecutablePath -like '*Programs\cursor*' })
  4. Trigger the app update (auto-update or reinstall).
  5. Observe the “Access is denied (os error 5)” delete failure, followed by a broken install with no top-level Cursor.exe.

Expected Behavior

Before updating, the updater should terminate the MCP/helper child processes Cursor itself spawned (or prompt the user to close them) and retry the locked operation. If the update genuinely cannot proceed, it should abort safely and roll back, leaving the previous working install intact — it should never delete the old Cursor.exe until the swap is guaranteed. Ideally, child MCP servers should not run on the bundled node located inside the install directory being updated.

Operating System

Windows 10/11

Version Information

Cursor 3.14.7 (User setup, per-user install at %LOCALAPPDATA%\Programs\cursor)
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42cf
Installer type: Inno Setup (unins000.exe)

[Replace this with the full Menu → About Cursor → Copy output so VSCode/Electron build strings match.]

Additional Information

  • The MCP server that triggered this in my case was launched from a workspace .cursor/mcp.json (npx --yes @elgato/mcp-server@latest), but the root cause is Cursor-side and reproduces with ANY stdio MCP server left running under the install dir.
  • Suggested fixes (any one materially reduces impact): (1) reap Cursor-spawned MCP/helper children before updating, then retry; (2) don’t run child MCP servers on the bundled node inside the install tree; (3) make the update transactional with rollback.
  • Workaround for affected users: kill stray processes under the install dir, then re-run the official User Setup installer silently (/VERYSILENT /SUPPRESSMSGBOXES /NORESTART). User settings/extensions (%APPDATA%\Cursor, %USERPROFILE%\.cursor) are unaffected.

Does this stop you from using Cursor

Yes - Cursor is unusable

8

Hi @rogerfsh Thank you for the post. This is an issue we’re tracking, and it isn’t caused by anything in your setup.

On Windows, a leftover MCP node.exe under the install folder can lock resources during an update. The updater can stop mid-way and leave Cursor unable to launch.

Your recovery steps are the right ones:

  1. Kill leftover processes under the install directory.
  2. Reinstall from Cursor · Download . Settings, extensions, and chats in %APPDATA%\Cursor and %USERPROFILE%\.cursor are kept.

To reduce the chance of a repeat:

  • Fully quit Cursor, including the tray icon, and check for leftover node.exe before updating.
  • Or set update.mode to none in Settings, then update with the downloaded installer, which prompts you to close conflicting processes first.

I’ll post here when I have an update.