That “Updating Cursor (3.21.13)” window is a small helper that shows update progress, and it sometimes keeps saying “Installing update…” even after the update itself has finished. The two threads you followed are about a different, older updater problem, so those steps would not have helped here.
Could you check which case you are in?
Quit Cursor
Open Cursor and click Cursor → About Cursor in the menu bar.
Note the version number.
If it already says 3.21.13, the update worked and the window is just a leftover. Open Activity Monitor, search for “update supervisor”, and Force Quit each entry (or run pkill -9 -f update-supervisor in Terminal). That is safe because the update is already done.
If it still says 3.20.21, leave the window alone for about 3 minutes. It should change to “Cursor couldn’t finish updating” with an Open Cursor button. Click that, then try Update once more. If it still does not go through, download the latest build from Cursor · Download and drag it into Applications over the existing app. Your chats, settings, and extensions are stored separately and stay intact.
Thanks for the instructions. In my case, it’s still say 3.20.21. I tried to tap “Open Cursor” button in the “Cursor couldn’t finish updating” window and then update Cursor again, but the installer was still stuck at “Installing update…” and then shown “Cursor couldn’t finish updating”.
Good news first: on our side it looks like your Mac did finish updating to 3.21.16 on Sep 20, about three minutes after your reply. It took a little over four minutes, which is longer than the progress window waits, so the window said “couldn’t finish updating” even though the update went through. Can you confirm by clicking Cursor → About Cursor in the menu bar?
What we would really like to understand is why updates on your Mac need so many tries. Cursor keeps a few local files that record exactly where each attempt stopped, and they would help a lot. Could you collect them?
In Finder, click Go → Go to Folder in the menu bar (or press Cmd+Shift+G).
Paste ~/Library/Application Support/Cursor/update-supervisor and press Enter.
Right-click the update-supervisor folder in the path bar (or select everything inside it) and choose Compress. This creates a zip.
Go → Go to Folder again, paste ~/Library/Caches/com.todesktop.230313mzl4w4u92.ShipIt and press Enter.
Compress that folder too (it contains ShipIt_stderr.log, which is the installer’s own log).
In Cursor, press Cmd+Shift+P, type Developer: Open Logs Folder and press Enter. Compress the folder that opens.
Optional but useful: open Terminal, run ls -ld@ /Applications/Cursor.app and paste the output.
Attach the three zips here (I can also open a DM with you if you prefer). They contain update progress and error messages only, no code or chat content.
Anybody else facing this issue (@Vihar_Donga, @Michael_Flores) this info would be a big help in figuring out what’s going on!
@Colin Adding data from another affected Mac. It’s also on macOS 27.0 (26A428) and has failed every in-app update since Sep 15 (3.20.21 → 3.20.23, 3.21.16, 3.21.18).
Attached: ShipIt_stderr.log and the Cursor logs folder from the session that started the last failed update. I had already cleared the update-supervisor folder before I saw your request, but I saved its results before deleting it:
shipit_attempts_exhausted (“Too many attempts to install, aborting update”)
overall_timeout (phase installing, 180096 ms)
version_mismatch ×2 (current 3.20.21, targets 3.20.23 and 3.21.16)
What the installer does: ShipIt logs “Beginning installation”, then exits about 6 seconds later with no error and no crash report. launchd reports “termination reported by launchd without exit status”, and the launchd status goes 0 → 113. The last thing ShipIt does is a trust check (com.apple.security.syspolicy / trustd). The supervisor then stays in installing indefinitely. After three tries ShipIt gives up.
The downloaded update was fine: codesign --verify --deep --strict passed, and spctl returned “accepted, Notarized Developer ID”.
Possible common factor: ls -ld@ on the app that kept failing, the same as @hieudinh’s:
I then installed the downloaded 3.21.18 bundle manually with ditto, and it has no quarantine attribute:
drwxr-xr-x@ 3 john staff 96 Jan 1 1980 /Applications/Cursor.app
com.apple.macl 72
com.apple.provenance 11
Both of us have com.apple.quarantine on an app installed from the DMG. Could that be what’s making ShipIt fail the trust check on macOS 27? I’ll report back on whether the next in-app update works now that the attribute is gone.
Hey @hieudinh and @Jwils, thanks for the logs, they helped a lot.
@hieudinh, you’re right, and I got that wrong earlier: the Sep 20 update was your manual install, not the in-app updater. Your logs and @Jwils’s show the same thing. The installer starts, then gets stopped from outside a few seconds after Cursor quits, before it changes anything. That points at macOS ending the installer, not at the downloaded update.
On macOS 27, one setting we have seen cause this is Cursor being turned off for background activity. Could you each check it?
Open System Settings → General → Login Items & Extensions.
Scroll to “Allow in the Background” and find Cursor.
Note whether it is on or off.
@hieudinh, please turn it on (or leave it on if it already is), then:
Quit Cursor.
Open Terminal and run defaults -currentHost delete com.todesktop.230313mzl4w4u92.ShipIt (this only resets the installer’s retry counter).
Open Cursor and click Update.
@Jwils, please just tell us what that setting shows and leave it as it is for now, so your next update tests the quarantine change on its own. We’d like to hear how it goes either way
If the next update fails for either of you, run this in Terminal right away and paste the output here:
log show --last 15m --predicate 'process == "loginwindow" OR process == "launchd"' | grep -i -E 'ShipIt|subordinate'
The “Allow in the Background” was the issue. Turning it on fixed issue. But i have one question that i turned that off as i don’t want my cursor or anything to run in background even they are off.
I Quit the Cursor from my mac but always it shows running in background. Can you please resolve it as it feels unnecessary using my resources?
Same issue, turning on “Allow in the Background” fixed it. But I don’t want that to be permanently turned on. I’m trying to conserve as much resources as possible, please let that be optional.
@Colin Confirming the same cause on my Mac. Cursor was off in “Allow in the Background”. Removing the quarantine attribute didn’t help: the 3.22.12 update still hung. Turning the setting on fixed it, and 3.22.12 then installed normally.
In case it helps you fix the updater so the setting isn’t required, here’s how macOS kills ShipIt. It’s from your log command, run right after the failure. Full output is attached.
16:52:05.065 launchd: [...ShipIt [2846]:] removing job: caller = loginwindow
16:52:05.065 launchd: [...ShipIt [2846]:] signaled service: Terminated: 15
16:52:10.067 launchd: [...ShipIt [2846]:] Service did not exit 5 seconds after SIGTERM. Sending SIGKILL.
When Cursor quits, loginwindow treats ShipIt as a subordinate process and kills it. Like others in this thread, I’d rather not leave background activity on permanently. Could ShipIt run so macOS doesn’t tie it to Cursor, or could the updater warn when this setting is off instead of hanging?
Hello, I had the same issue and the problem (at least for me) was turning off Cursor’s “Background App Activity”. On MacOS go to System Settings–>General–>Login Items and look for Background App Activity. Toggling that on let its updater do its thing.
Thanks for the help!