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.
Hey, thanks for the details. This is exactly what we needed. The com.apple.quarantine attribute on the app is probably the cause. If /Applications/Cursor.app has the quarantine flag, Gatekeeper can quietly block the ShipIt helper process from launching. That matches your logs. The co.anysphere.cursor.*.ShipIt folder never gets created because ShipIt never starts.
Let’s test that. Remove the quarantine attribute and try the in-app update again:
Make sure the flag is gone: xattr -l /Applications/Cursor.app (you should not see com.apple.quarantine)
Wait for the next update (or trigger a manual check) and click Install and Restart
Let me know if the update applies after this. If it does, quarantine was blocking ShipIt, and that really helps us narrow down the root cause. If it still stays on the old version, tell me too and we’ll dig further.
We’ve confirmed the repro on the latest stable and I’ve passed your data to the team. There’s no ETA for a fix in the updater yet, but as soon as we have an update, I’ll reply here.
I attempted to remove the quarantine flag from /Applications/Cursor.app using xattr -dr com.apple.quarantine /Applications/Cursor.app, which failed with Operation not permitted.
Running the same command under sudo also failed. To determine whether the restriction was specific to the quarantine attribute or to all extended attribute writes on that bundle, I ran xattr -w test.foo bar /Applications/Cursor.app — a write of a harmless dummy attribute — and that also failed. The same test on another app (/Applications/Audacity.app) succeeded, ruling out a general /Applications restriction.
Also tried in MacOS settings (Privacy and Security > Security) to find any “Unknown developer” / “Run anyway” buttons to remove the flag but couldn’t find any (I’m on Taho 26.2 btw).
My research:
The reason Cursor’s bundle is immutable to extended attribute modification — even by root — is the presence of com.apple.macl, a kernel-managed attribute set by macOS’s TCC subsystem whenever an app is granted privacy permissions (Full Disk Access, Accessibility, etc.).
Cursor holds those grants because it requires them to function as an IDE. Once com.apple.macl is on a bundle, the kernel enforces immutability on that bundle’s extended attributes at the syscall level, regardless of user, sudo, or filesystem permissions.
Audacity has no com.apple.macl because it has no TCC grants, which is why the same xattr -w test passes on it. The quarantine flag cannot be removed through any standard user-space tool while com.apple.macl is in place.
This is a great debug, thanks. Your diagnosis is correct. com.apple.macl really does make a bundle’s xattrs immutable, so you can’t remove the quarantine flag because of that. One important detail is that com.apple.macl itself is protected by SIP, so you can’t remove it via xattr, tccutil, or even with sudo. The only ways are with SIP disabled or by booting from another volume. So you can’t reliably unlock the current bundle in place to clear quarantine.
The most reliable path is to not fight xattrs on the existing bundle, and instead do a clean reinstall:
Fully quit Cursor with Cmd+Q.
Drag /Applications/Cursor.app to Trash and empty it.
Your settings, extensions, and chat history will stay since they’re stored separately from the app bundle. A freshly installed copy won’t carry the old macl, so there’s a good chance in-app update will work after that.
If you still want to try clearing quarantine without a full reinstall, you can do a couple of independent attempts. Each one can help on its own, but there’s no guarantee because of SIP and macl:
Reset TCC bindings:
tccutil reset All "$(mdls -name kMDItemCFBundleIdentifier -raw /Applications/Cursor.app)"
If xattr -dr still returns Operation not permitted, that’s SIP plus com.apple.macl, and then you’ll need the clean reinstall steps above.
Let me know if quarantine got removed and if the in-app update applied after a clean reinstall. That’ll really help us pin down the root cause. The updater is on our side, there’s no ETA for a fix yet, but I’ll post in the thread once we have one.
Let me know if quarantine got removed and if the in-app update applied after a clean reinstall
I think its fixed.
After following your instructions for clean reinstall (delete it, empty recycle bin, download and install), I was able to confirm the following:
The app is marked quarantined after having been installed. (checked with xattr -l /Applications/Cursor.app)
I am able to remove the quarantine on the cleanly reinstalled app by doing xattr -dr com.apple.quarantine /Applications/Cursor.app
To test if the auto-update works I intentionally downloaded an older version (3.7.42) and waited for the update banner to come up. When it did I pressed Update and it worked as expected, with the new version (3.8.11) installing and then Cursor restarting automatically.
Awesome, glad it’s working, and thanks for the detailed debug. Your digging into com.apple.macl and immutable xattrs really helped us understand why ShipIt wasn’t starting and didn’t show any errors.
Quick steps for anyone who hits the same issue on macOS:
Fully quit Cursor with Cmd+Q
Delete /Applications/Cursor.app and empty the Trash
Optional, remove quarantine with xattr -dr com.apple.quarantine /Applications/Cursor.app
Your settings, extensions, and chat history will stay. They’re stored separately from the app bundle.
I’ve shared the full write-up with the team, including the quarantine and macl behavior that was blocking ShipIt. No ETA for an updater fix yet, but I’ll reply here once there’s an update. If in-app update starts failing again, let me know.
