Cursor couldn’t finish installing the update to version 3.6.31
Steps to Reproduce
Just launch Cursor, notice that it fails to update.
Clicking on Try again seems to be attempting to install the update (cursor closes) but it just never reopens and next time its opened manually the same message is shown and Cursor is not updated.
Hey, thanks for the report. This is a known issue with the auto-updater on macOS. Sometimes it can’t apply an update and keeps showing this toast in a loop, while Cursor continues running on the old version.
The most reliable workaround is to reinstall manually:
Open the downloaded .dmg and drag Cursor into Applications, replacing the current version
Your settings, extensions, and chat history will be kept. This is just replacing the app binary, not a clean reinstall.
This is a bug on our side, and we don’t have an ETA for a fix yet. If the update still fails after the manual reinstall, or if Cursor won’t launch, let us know and we’ll take a closer look.
Hey @MaxBCM just wanted to check if you were able to install the latest version using a manual reinstall from Cursor · Download? The current stable is 3.7.21.
If the manual reinstall worked and Cursor launches normally, can you check if in-app updates now apply without the same error? If the failed update toast still comes back or Cursor won’t open after an update, let me know and we’ll take a closer look. If you can, please include:
the version you’re on right now (Cursor > About)
whether the error shows up again on the next in-app update
There’s no timeline yet for a fix to the auto-updater itself, but I want to make sure you’re at least on the latest version and not stuck.
Unfortunately shortly after another update was available and I clicked on the Install and Restart banner and it failed.
This is not a good user experience, if everytime an update becomes available I have to interrupt what I am doing and manually download the update from the website.
@MaxBCM thanks for coming back with more details, I can see the screenshot showing the update failing on 3.7.19.
You’re right, and I totally agree. Having to do a manual download for every update isn’t the experience it should be. This confirms the bug is in the in-app auto-updater on macOS. On restart, Cursor quits, but the update doesn’t apply, and it reopens on the old version. Manually reinstalling fixes that specific version, but not the updater itself, so the next in-app update fails again.
This is on our side, and I’ve re-flagged it internally with your fresh data (3.7.12 → 3.7.19) since it still repros on the latest stable. Honestly, I don’t have an ETA for a fix yet, and until then the only reliable workaround is a manual download from Cursor · Download.
I know that’s annoying. As soon as there’s an update on the fix, I’ll reply in this thread.
@MaxBCM, to dig into the root cause of why ShipIt isn’t applying the update on macOS, can you share a couple of logs? They’ll help us see which step the process is failing at:
Fastest way to get there: in Finder press Cmd+Shift+G, paste the path, then hit Enter. Zip both folders and attach them here. If anything’s sensitive, you can email them to [email protected] and include a link to this thread.
If you can, grab the logs right after another failed update attempt so they’re as fresh as possible. The manual download workaround still works for now, but we need these logs to get to the real cause.
…and then the next log session still shows version 3.7.12 — meaning the install never applied
The app restarts at the same version every time. Since there’s no ShipIt folder in the cache, ShipIt is either not running or crashing silently before it can write logs. That’s the
smoking gun — doQuitAndInstall() hands off to ShipIt, but ShipIt never executes the swap.
What to tell the Cursor admin: The update downloads and reaches ready state successfully every time. doQuitAndInstall() fires, the 5-second kill watchdog arms, but Cursor restarts at
version 3.7.12 unchanged. The ShipIt cache folder (co.anysphere.cursor.*.ShipIt) does not exist at all, suggesting ShipIt never ran. The failure is in the handoff between
doQuitAndInstall() and ShipIt, not in the download phase.
Thanks for the logs and the write-up, it really helps. The key finding matches what I’m seeing too: the update downloads and reaches ready, doQuitAndInstall() gets called, but the ShipIt cache folder co.anysphere.cursor.*.ShipIt isn’t there at all. That means ShipIt never starts, so the binary swap never happens. The failure is in the handoff between doQuitAndInstall() and ShipIt, not during download. I’ve passed this along internally with your latest details (3.7.12 → 3.7.19), and we’ve confirmed a repro on the current stable build. No ETA for an updater fix yet, but I’ll post here as soon as there’s an update.
When ShipIt silently doesn’t launch on macOS, a common cause is where and how the app is installed. Can you confirm a couple things so we can narrow down the root cause:
Where is Cursor.app installed, exactly in /Applications or somewhere else like Downloads or your home folder?
What do you get in Terminal from: xattr -l /Applications/Cursor.app
We’re checking for com.apple.quarantine.
After the next failed update attempt, please check Console.app → Crash Reports and see if there are any crashes mentioning ShipIt or Cursor around the restart time.
Manual download from Cursor · Download is still the working way to update for now. I know it’s annoying to do every time.
Where is Cursor.app installed, exactly in /Applications or somewhere else like Downloads or your home folder?
In Applications
Blockquote
2. What do you get in Terminal from: xattr -l /Applications/Cursor.app
We’re checking for com.apple.quarantine.
Yeah its quarantined
Blockquote
3. After the next failed update attempt, please check Console.app → Crash Reports and see if there are any crashes mentioning ShipIt or Cursor around the restart time.
