The editor update that deletes the editor
TL;DR: Cursor and other VS Code-based editors on Windows can delete themselves during an update when a stdio MCP server still runs the editor's bundled node.exe. Recover by moving the staged build out of the _ folder, and kill those processes before updating.
Twice this month an auto-update on Windows left me with no editor at all. The shortcut pointed at nothing, and the update log claimed success.
What happens
The editor (Cursor, but the updater comes from VS Code) stages the new build in a _ subfolder. The updater then deletes the old install before moving the new one into place. Before it starts, it only checks whether the main .exe is still running.
The editor puts its own bundled node.exe first on PATH when it starts stdio MCP servers. So npx some-mcp-server runs on the editor's node, and that process keeps running after the window closes. The delete hits a locked file, gives up after retries, and leaves a half-deleted install with the new build stranded in _.
Recovering
No reinstall needed. Delete the gutted resources folder, move everything from _ up one level, delete _.
Preventing it
I turned off auto-update ("update.mode": "none") and check for stragglers before updating by hand:
Get-Process | Where-Object { $_.Path -like '*\cursor\resources*' }Turning the server off in the editor's MCP settings is not enough. One server's child processes survived the toggle. Trust the process list, not the UI. HTTP-based MCP servers don't spawn anything local, so only stdio ones matter.