Windows updater hangs while Remote Control agent worker is running

[_duncan]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When updating Cursor on Windows, the updater remained stuck on “Still updating Cursor…” for more than 15 minutes while I had agent worker start running in a separate terminal for Cursor Remote Control.
I stopped the agent worker start process, and approximately 1–2 minutes later the Cursor update completed successfully.
I cannot confirm that the worker was definitely the cause because I have only observed this once, but the timing strongly suggests that the running agent worker may have been holding a Cursor-related process or file open and preventing the updater from completing.
The updater did not display an error or indicate that another Cursor process needed to be stopped.

Steps to Reproduce

1. Start Cursor on Windows.
2. Open a terminal.
3. Run:
   agent worker start
4. Leave the worker running.
5. Start a Cursor update.
6. The updater may remain stuck on “Still updating Cursor…” near the end of the progress bar.
7. Stop the agent worker start process.
8. In my case, the update then completed approximately 1–2 minutes later.
   I have only encountered this during one update so far, so I cannot yet confirm that it reproduces every time.

Expected Behavior

Cursor should be able to update while the agent worker is running. If the worker cannot remain active during an update, the updater should detect this and clearly tell the user that agent worker start or another Cursor process must be stopped before the update can continue, rather than appearing to hang indefinitely.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.19.19 (user setup)
VS Code Extension API: 1.128.0
Commit: 6496ea8a068aebfcd21990e70ff522e9abf10c80
Date: 2026-09-08T16:25:33.352Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

Additional Information

The update had already been stuck for more than 15 minutes before I stopped the worker.
I did not terminate the updater or make any other changes. The only action I took was stopping the terminal process running agent worker start. The updater then completed on its own about 1–2 minutes later.
I use agent worker start for Cursor Remote Control.
This may be related to the worker keeping a Cursor-related file or other resource open during the Windows update, but that is only a hypothesis based on the observed behavior.
I have attached a screenshot of the updater while it was stuck.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Colin]

Hey @_duncan, thanks for the detailed report.

Could you send us these three things from that update?

1. %APPDATA%\Cursor\logs\ : the folder with the timestamp closest to when Cursor came back (around 12:33 your time today), specifically its main.log.
2. %TEMP%\cursor-inno-updater-*.log : any files from today.
3. %APPDATA%\Cursor\update-supervisor\win32\ : the whole folder.

Also, two quick questions: was agent worker start running in Cursor’s built-in terminal or in a separate Windows Terminal / PowerShell window?

Let me know if you’d rather me open up a DM for you to share the logs.

[_duncan]

Cursor-update-diagnostics.zip (1.5 MB)

Hi Colin, thanks for looking into this.

I’ve attached a ZIP containing:

• 20260909T123258/main.log, from when Cursor came back around 12:33.

• cursor-inno-updater-1788948830.log, dated September 9.

• The win32 folder, including its installation subfolder with state.json and inno_updater.exe.

I’ve replaced my Windows username in the log paths with USER for privacy. The supervisor files are unchanged.

agent worker start was running in a separate terminal window.

Please let me know if you need anything else.

[Colin]

Hi @_duncan, thanks again for sending those logs, and sorry for the slow reply on our side.

They were useful. The file replacement itself finished in about 6 seconds with no locked files, so the worker was not holding anything in the install folder. The wait was entirely between the update finishing and Cursor starting up again: the new Cursor did not start until 12:32:58, about 19 minutes after the files were swapped.

To see what happened in that gap, could you send two more things from September 9?

1. The installer’s own log. In File Explorer, paste %TEMP% into the address bar and look for files named like “Setup Log 2026-09-09 #001.txt”. Please send all of them from that day.
2. A listing of your Cursor log folders from that window. Open a Command Prompt and run:

dir "%APPDATA%\Cursor\logs" | findstr 20260909

and paste the output here.

One question as well: when Cursor came back, did you start it yourself (taskbar, Start menu, double-click), or did it appear on its own?

If you get another update before then, a re-test would tell us a lot:

1. Start agent worker start in a separate terminal window, as before.
2. In Cursor, choose Restart to Update.
3. If the window sits on “Still updating Cursor…” for more than 2 minutes, open Task Manager, go to the Details tab, and note whether any Cursor.exe or inno_updater.exe entries are listed.
4. Wait another 2 to 3 minutes, then stop the worker with Ctrl+C and note whether Cursor appears within a couple of minutes.
5. Once Cursor is back, send the new “Setup Log” and cursor-inno-updater log from %TEMP%.

[Erik2]

This happens to me every time I update it regardless if agents are running or not, on two different (windows) computers, it just stays with this dialog animating the green bar indefinitely.

If I just start cursor it will close that dialog by itself and seem to be updated to the latest version.

(and no, I cant be bothered to fiddle around on my harddrive to locate logs, just wanted to share since this was the topic that showed up during a internet search for “still updating cursor”)

[Ciprian_Nastase]

I am also getting the exact same behavior, and with Cursor’s almost daily updates, it is becoming frustrating.

[Brent_Rowe]

Same behavior here, but it is not specific to the Remote Control worker. I have no agent worker start running and it happens on every single update: 3.21.9, 3.21.13 and 3.21.16, Windows 11 (10.0.26200), user setup.

Answering Colin’s question directly, since it is the crux: I start Cursor myself every time. The updater window never closes on its own, and it disappears the instant I launch Cursor from the Start menu. Logs from this morning’s 3.21.16 update, which I think close the gap you identified.

1. Install and promotion both succeed, and nothing ever launches Cursor

%TEMP%\Setup Log 2026-09-21 #001.txt (local time, UTC-5):

08:22:17.333   Installation process succeeded.
08:22:17.334   Checking whether application is still running...
08:23:44.032   Application appears not to be running.
08:23:57.620   Need to restart Windows? No
08:23:57.632   Deinitializing Setup.
08:23:57.664   Log closed.

No Run entry is executed anywhere in that log, so the installer never performs the equivalent of Inno’s runcode task.

%TEMP%\cursor-inno-updater-1789997024.log (this one logs in UTC):

13:23:44.140 INFO Starting: C:\APPDIR\cursor\Cursor.exe, false, Updating Cursor...
13:23:44.160 INFO Cursor.exe is not running
13:23:44.188 INFO do_update: "C:\APPDIR\cursor\Cursor.exe", _
13:23:50.194 INFO All files deleted
13:23:57.547 INFO Update was successful!

That is the last line in the file. Promotion took 13 seconds and reported success. There is no launch attempt and no error after it.

2. The supervisor stops at promotion_complete, waiting on a file only a running Cursor can write

%APPDATA%\Cursor\update-supervisor\win32\7a5e5d33-759b-4fdc-a8f9-40659eaae918\:

state.json       written 08:23:57   {"schemaVersion":1,"installationId":"7a5e5d33-...","stage":"promotion_complete"}
app-ready.json   created 08:25:35   {"schemaVersion":1,"installationId":"7a5e5d33-...","currentVersion":"3.21.16"}

The stage is visible on screen: the window title is literally Cursor Update - promotion_complete, on the same dialog duncan screenshotted. It sat there from 08:23:57 until 08:25:35, which is when I launched Cursor by hand. app-ready.json is written by the newly started Cursor in onUpdateRestartCompleted, so unless something starts Cursor the supervisor waits forever while the window says “Still updating Cursor…”. The user is waiting on the supervisor and the supervisor is waiting on the user.

The 97 seconds is just how long it took me to get suspicious. The stall is unbounded, which is presumably how duncan got 19 minutes.

3. The acknowledgement line cannot be used as a success signal

%APPDATA%\Cursor\logs\20260921T082004\main.log:

08:23:42.766 [info] [UpdateSupervisor] Prepared Win32 supervisor (installationId=7a5e5d33-..., targetVersion=3.21.16)
08:23:43.729 [info] [UpdateSupervisor] Armed Win32 supervisor (installationId=7a5e5d33-..., pid=13788)

Then in the next session, 20260921T082534\main.log:

08:25:35.541 [info] [UpdateSupervisor] Win32 restart acknowledged (installationId=7a5e5d33-..., currentVersion=3.21.16)

That acknowledgement is written by whichever Cursor starts next, regardless of who started it, so a manual launch produces exactly the same line as an automatic relaunch. If restart health is tracked from this, the numbers will look fine while people are relaunching by hand. There is also no log line for a relaunch attempt or its failure, which is what makes this undiagnosable from the user side. For completeness: I run CrowdStrike Falcon, which could plausibly block a spawn originating from inno_updater.exe, but with no attempt logged I cannot tell “blocked” apart from “never tried”.

4. There look to be two separate effects in this thread

• How long the installer waits for the old app to exit. Mine was 87 seconds (08:22:17 to 08:23:44) with nothing unusual running. A lingering Cursor helper like duncan’s agent worker start stretching this is consistent with his worker being the trigger for the duration.
• The relaunch never happening at all. Independent of the above, reproduces with no worker running, and is what Erik2 and Ciprian_Nastase are describing.

Reproduced on 3.21.9 (2026-09-17, installationId 5ad26307-…), 3.21.13 (2026-09-18, 80751222-…) and 3.21.16 (2026-09-21, 7a5e5d33-…). Every one ended with me starting Cursor manually.

Minor and related: each update leaves %TEMP%\vscode-stable-user-x64-<random>\CodeSetup-stable-<version>.exe behind, roughly 200 MB per update, and nothing ever removes it.

Version information

Version: 3.21.16 (user setup)
Commit: 8ae78e8eee1e63479c7e0504b664bc0a80c68000
Date: 2026-09-19T06:43:22Z
Build Type: Stable
OS: Windows_NT x64 10.0.26200

Artifacts for all of the above are attached in my reply below.

Edited: this is a work machine, so the install directory name is replaced with APPDIR here and in the attached logs. Nothing else changed.

[Brent_Rowe]

cursor-171151-artifacts.zip (1.8 MB)

Attaching the artifacts rather than waiting to be asked. The zip contains:

• logs\20260921T082004\main.log and logs\20260921T082534\main.log - the session that armed the supervisor and the session that acknowledged the restart, complete.
• logs\20260918T105006\main.log and logs\20260918T125403\main.log from the 3.21.13 update, filtered to the update lines only.
• update-supervisor\win32\7a5e5d33-.\ with state.json and app-ready.json. I left out inno_updater.exe, since that is your own binary.
• cursor-inno-updater-1789679774.log, -1789754020.log, -1789997024.log and Setup Log 2026-09-17 #001.txt, 2026-09-18 #001.txt, 2026-09-21 #001.txt - one pair per update for 3.21.9, 3.21.13 and 3.21.16.

This is a work machine, so the files are sanitized: Windows user name replaced with USER, the install directory name replaced with APPDIR (so paths read C:\APPDIR\cursor), the per-install identifier in the updateURL replaced with MACHINE-ID-REDACTED, and an internal host name replaced. Timestamps, ordering, and every update, supervisor and installer line are unmodified. A README.txt in the zip lists the same substitutions. For the same reason I have edited the install path in my post above to match.

[Colin]

Hey @Brent_Rowe, thanks for the logs, they answer the question.

Your installer logs confirm that the update itself completes normally and that the step that should start Cursor afterwards is never run. We have found the cause on our side: when Cursor was originally installed with a “do not launch after install” option (for example, winget install Anysphere.Cursor uses /mergetasks=!runcode), Windows remembers that choice, and our updater currently inherits it on every update instead of overriding it. So the update finishes, nothing starts Cursor, and the “Still updating Cursor…” window waits for a launch that never comes. I’ve flagged this to the team.

One clarification on the 87 seconds you measured: that gap is the installer waiting for you to accept the update (staging finished at 08:22:17, you clicked Restart to Update at 08:23:42), not a lingering process. So there is really just one effect here.

Could you confirm the cause on your machine? In a Command Prompt, run:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall" /s /f runcode /d

and paste the output here. If it shows Inno Setup: Deselected Tasks ... runcode, that is the state I described. It would also help to know whether Cursor was installed with winget or an IT deployment script on that machine.

Until the fix ships, two things help:

1. When the window sits on “Still updating Cursor…”, just start Cursor from the Start menu. The update has already been applied, and the window closes on its own.
2. To make future updates relaunch on their own, close Cursor, download the installer from Cursor · Download and run it normally. It installs over the top and keeps your settings, and running it once clears the remembered “do not launch” choice. A later winget upgrade would set it again, so this is a stopgap until our fix is out.

@Erik2 and @Ciprian_Nastase, the same check and workarounds apply to you. If you can paste the output of that command as well, it would confirm you are hitting the same thing.

@_duncan, this most likely explains your case too: the worker was a coincidence, and Cursor came back when you started it. If you can run the same command and let us know whether you started Cursor yourself that day, we can close the loop.

[Brent_Rowe]

Confirmed. reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall" /s /f runcode /d:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{DADADADA-ADAD-ADAD-ADAD-ADADADADADAD}}_is1
    Inno Setup: Deselected Tasks    REG_SZ    desktopicon,runcode

(The other match, {771FD6B0-...}_is1 with Selected Tasks = runcode, is an unrelated app.)

desktopicon is deselected as well, so the original install was done with non-default options: custom directory, no desktop icon, no launch-after-install. It was not winget. The custom path and the deselected desktop icon point to the downloaded installer run by hand with options changed; I have no IT deployment record for it. winget list does show Anysphere.Cursor 3.21.16, but that is just winget matching the ARP entry to its catalog; there are no winget install logs for it on this machine.

Agreed on the 87 seconds, that is me clicking Restart to Update, not a lingering process. One effect, and you have found it. Thanks.

[Ciprian_Nastase]

Ok, I ran the command you mentioned, and i see this:
Inno Setup: Deselected Tasks REG_SZ desktopicon,addcontextmenufiles,addcontextmenufolders,runcode

For context of where/how I installed it: first time install was done through the downloader; however, I am using UniGet and sometimes I install the Cursor updates via UniGet.

In my case, if I start Cursor from the taskbar pinned apps, it will also make the innoupdater go away (I don’t necessarily have to start it from the Start Menu)

[Colin]

Hi @Brent_Rowe and @Ciprian_Nastase, thanks for running the check. Both outputs show the state I described, so you are on the same issue’

One detail, since Brent asked: that registry line is rewritten by every silent install, including Cursor’s own updates, so it reflects the current state rather than its origin. Any install that ran once with the “do not launch afterwards” option (winget, UniGet, Chocolatey, an IT setup script) is enough to set it, and our updater then carries it forward on every update instead of overriding it.

I’ve flagged it to the team.

Until then, two options:

1. If the window sits on “Still updating Cursor…”, just start Cursor (Start menu or taskbar). The update is already applied and the window closes on its own.

2. To make updates relaunch on their own again, you can remove that remembered choice yourself. Cursor can stay open, and no admin rights are needed for a per-user install. Open PowerShell and run this as a single line:

$k = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\{DADADADA-ADAD-ADAD-ADAD-ADADADADADAD}}_is1'; $n = 'Inno Setup: Deselected Tasks'; $v = (Get-ItemProperty -LiteralPath $k -Name $n).$n; Set-ItemProperty -LiteralPath $k -Name $n -Value (($v -split ',' | Where-Object { $_ -ne 'runcode' }) -join ',')

It only removes runcode from that value and leaves your other choices (desktop icon, context menu entries) as they are. If your earlier reg query printed a different key name than the one above, use that key instead. Run the reg query from my earlier post again afterwards and runcode should be gone from the line.

From the next “Restart to Update” on, Cursor starts on its own again, and it stays that way unless something installs Cursor with the “do not launch” option again (a winget or UniGet update would; updates from inside Cursor or the cursor.com installer will not). Reinstalling from cursor.com as described earlier does the same thing, this is just quicker.

@Erik2 and @_duncan, if you can run the same command from my earlier post and paste the output, that would confirm you are hitting the same thing. Either way, starting Cursor by hand is the workaround for now, and if your output shows runcode on that line, the PowerShell command above applies to you too.