Windows update fails with duplicate error dialogs: Cursor.exe file lock + "installation already running"

Support Bug Reports
,
1

On Windows, Cursor’s update flow can fail with two separate, developer-facing error dialogs instead of one coordinated update:

  1. File handle error — cannot replace C:\Users\Crafter\AppData\Local\Programs\cursor\Cursor.exe because another process holds the file.
  2. Inno Setup error — “An installation is currently running” (CodeSetup-stable-3.9.16).

After failure, orphaned installer processes remain (CodeSetup-stable-3.9.16, CodeSetup-stable-3.9.16.tmp, inno_updater), blocking retries until the user kills them in Task Manager.

An IDE should use a single update path, ensure all Cursor processes exit before binary replacement, and show one clear recovery message—not raw file-handle errors.

Steps to reproduce

  1. Run Cursor on Windows with auto-update (or trigger update in-app).
  2. While Cursor is running, let auto-update run or launch CodeSetup-stable-*.exe manually.
  3. See one or both error dialogs.
  4. Task Manager shows stuck CodeSetup / inno_updater processes.

Expected: One updater at a time; full process shutdown before replacing Cursor.exe; single user-facing error with retry/cleanup; no zombie installers.

Actual: Dual errors; manual Task Manager cleanup required; issue can recur.

Environment

  • Cursor 3.9.16
  • Windows 10.0.26200 (Windows 11)
  • Install: C:\Users\Crafter\AppData\Local\Programs\cursor\Cursor.exe

At incident time: 15 Cursor.exe processes; stuck CodeSetup-stable-3.9.16, CodeSetup-stable-3.9.16.tmp, inno_updater.

Suggested fixes

  1. Single update coordinator (mutex for in-app updater vs manual CodeSetup).
  2. Process shutdown gate before replacing Cursor.exe.
  3. One unified error UI with Retry + auto cleanup of orphan installers.
  4. On startup, kill stale CodeSetup / inno_updater from failed runs.
  5. Avoid dual update paths when one is already active.

Attachments: 2 screenshots (file handle error + “installation already running”).

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

Hey, thanks for the detailed report. The breakdown by processes and steps really helps.

This is a known issue on our side. During an update, orphaned processes like extra Cursor.exe, rg.exe, and stuck CodeSetup-* or inno_updater can keep handles on the install directory. That makes the binary swap fail, and then the second installer hits the Inno Setup mutex and shows installation already running. We’re tracking the issue, but I can’t share an exact ETA for a fix yet.

How to recover right now:

  • In Task Manager, end any stuck processes: CodeSetup-stable-*, inno_updater, and any extra Cursor.exe.
  • Reinstall Cursor from Cursor · Download. Your settings and extensions will be kept at %APPDATA%\Cursor and %USERPROFILE%\.cursor. Only the binary gets replaced.

To reduce the chance it happens again:

  • Fully quit Cursor before restarting or shutting down Windows, including the tray icon.
  • Don’t run CodeSetup manually while auto-update is running.
  • If this is a work machine, add %LOCALAPPDATA%\Programs\cursor to your AV or endpoint protection exclusions so it doesn’t hold file handles during the swap.
  • If you want to disable auto-update for now: Settings → search for update.mode → set it to none and update manually.

Let me know if the issue comes back after cleaning up the processes and reinstalling.