The last 2 updates of cursor on macos left the installer hanging in the middle of the update process. However, cursor restarts and seems to work anyway (with the correct version: 3.17.8 here). See CleanShot 2026-08-22 at 11.40.30 · CleanShot Cloud for hanged installer.
Steps to Reproduce
Install update of cursor from cursor “update” blue button
Maybe an update got pulled? Same thing happened to me, I’m on 3.17.8 as well (updated to this version 2 days ago), but “Check for Updates” says there are none.
Hey @Vincent_Keunen , your install looks healthy. That’s a newer macOS update-progress window that sometimes lingers after Cursor has already relaunched on the new version (you’re on 3.17.8), so it’s safe to just close it if it hangs. Nothing on your end - it’s an issue we’re tracking, and I’ll follow up here when there’s an update.
@RayGraham - same thing, and your update did land. “Check for Updates” showing none just means you’re already on the latest, so nothing was pulled.
Those stuck “Updating Cursor” panels are just a leftover helper process, not Cursor itself, so there’s no need to reboot: open Activity Monitor, search “update supervisor,” and Force Quit each stacked entry (or in Terminal, pkill -9 -f update-supervisor). It’s safe since the update has already finished. It’s an issue we’re tracking, and that same step clears them if they show up again.
Every update has the same problem (6 or 7 times); only on my powerbook. Works ok on a mac mini.
More:
Hi Cursor team — stuck “Updating Cursor / Installing update…” window on one Mac only.
Summary
After every in-app update for the last ~6–7 releases, the small “Updating Cursor (x.y.z) — Installing update…” dialog stays open forever on this machine. The update itself succeeds (new build launches and works). On my other Mac, the same dialog closes normally.
Environment (affected machine)
macOS 27.0.1 (Build 26A434), Darwin 27.0.0, Apple Silicon
Cursor just updated 3.22.12 → 3.23.12 (same hang pattern on prior updates)
What we observed while the dialog was still open
The dialog is owned by cursor-update-supervisor (under ~/Library/Application Support/Cursor/update-supervisor/<installationId>/), not by a stuck ShipIt install.
ShipIt completed successfully (ShipIt_stderr.log: “Installation completed successfully”, new app launched). Disk app is 3.23.12; new Cursor main process is running.
app-ready.json was written for the new version/pid, but result.json was never written and events stopped at phase installing.
Supervisor main thread was blocked in SupervisorApplication.poll() → launchdSnapshot() → NSTask waitUntilExit on: launchctl print gui/501/com.todesktop.230313mzl4w4u92.ShipIt
That child launchctl was stuck in __write_nocancel on its stdout/stderr pipes back to the supervisor; both pipe buffers were full (~16KB). Classic NSTask deadlock: parent waits for exit without draining pipes; child blocks once output exceeds the pipe buffer.
A separate launchctl print of the same job (from a terminal) returned immediately with small output after ShipIt had finished — so the hang is specific to the supervisor’s piped NSTask, especially when print output is large mid-install.
Historical pattern on this Mac: many prior update-supervisor/<id>/ folders have app-ready.json but no result.json (only a couple ever got result=success), matching “update works, UI never finishes” for months.
Likely bug cursor-update-supervisor should not waitUntilExit on launchctl print without asynchronously reading stdout/stderr (or use a temp file / standardOutput = .nullDevice if output isn’t needed). On newer macOS, launchctl print for an in-flight ShipIt job can be large enough to fill the pipe and deadlock the progress UI forever.
Workaround
Killing the supervisor PID (or force-quitting that dialog) is safe; Cursor is already on the new version.
@Vincent_Keunen your diagnosis matches what we found, thanks for digging in. We’ve passed it to the team, so no need for extra logs. I’ll post here when there’s a fix.
