Cursor IDE Update Not Applying: Fix the Restart Loop

April 15, 2026 · Editorial Team · 5 min read · cursor troubleshooting error-fix

You're in the middle of a coding session, Cursor 0.47 is open, and that little notification badge shows up again: "Update Available." You click it, Cursor says it'll restart to apply the update, and then... it comes back up on the same version. The badge is still there. You click again. Same thing. Five restarts later you're still on 0.46 and increasingly annoyed. This is one of those bugs that feels minor until it blocks you from getting the AI features that shipped in the new version, and it can quietly persist for days before you realize Cursor hasn't actually updated at all.

What this error actually means

Cursor ships updates through its own auto-updater, which downloads a binary delta or full package to a temp directory and then attempts to swap it in on restart. When the swap fails silently, Cursor re-launches on the old binary and the updater kicks off again, creating the loop you're seeing.

The actual update payload lands in:

macOS: ~/Library/Application Support/Cursor/pending/
Linux: ~/.config/Cursor/pending/
Windows: %APPDATA%\Cursor\pending\

If something is holding a lock on the Cursor binary (a background process, a crash reporter, or even your antivirus scanner), the atomic file rename that completes the update can't happen. On macOS specifically, Gatekeeper quarantine sometimes flags the downloaded binary and blocks execution before the swap completes.

Quick fix (when you need it working in 60 seconds)

Quit Cursor completely. Don't just close the window. On macOS: Cmd+Q or right-click the dock icon and choose Quit.
Open Activity Monitor (macOS) or Task Manager (Windows) and kill any remaining Cursor or cursor_crashpad_handler processes.
Delete the pending update directory: rm -rf ~/Library/Application\ Support/Cursor/pending/ (macOS) or the equivalent path on your OS.
Relaunch Cursor. It will re-download the update fresh and try again.
If it still loops, jump to the permanent fix below.

Why this happens

This loop has a handful of common root causes, and knowing which one you're hitting changes how you fix it.

The most common cause on macOS is a leftover process lock. Cursor's crash reporter, cursor_crashpad_handler, sometimes outlives the main window and holds the binary open. When the updater tries to rename the new binary into place, macOS won't allow it because the file is in use. The update "succeeds" from the updater's perspective but the actual swap never happens.

The second cause is a corrupted partial download in the pending directory. If your internet dropped while the update was downloading, or your disk ran low on space, the pending binary can be incomplete. Cursor's updater doesn't always detect this and will keep trying to apply a broken file.

On Linux, particularly with Snap or Flatpak installs, the auto-updater is disabled entirely because those package formats control updates through their own channels. Cursor doesn't always make this obvious, so you see the "update available" badge (which comes from a server-side check) but the install never works because the updater binary isn't even present.

Windows Defender and other antivirus tools are another culprit. They scan the downloaded binary before Cursor can execute it, and occasionally quarantine it or hold it long enough that the update times out.

Finally, permission issues on the Cursor install directory can block the update. If you installed Cursor as a different user or under a corporate managed setup, the current user may not have write access to the application directory.

Permanent fix

Completely quit Cursor and all related processes as described above.

Clear the pending update cache:

# macOS/Linux
rm -rf ~/Library/Application\ Support/Cursor/pending/
rm -rf ~/Library/Application\ Support/Cursor/updates/

On macOS, remove the Gatekeeper quarantine attribute from the Cursor app:
```
xattr -dr com.apple.quarantine /Applications/Cursor.app
```
If you're on Linux via Snap, update through snap instead of through the in-app updater:
```
sudo snap refresh cursor
```
On Windows, right-click the Cursor shortcut, choose "Run as administrator", then trigger the update. This handles permission issues with managed installs.
If none of that works, do a clean reinstall. Download the latest .dmg or .exe from cursor.sh directly, quit Cursor, uninstall it, and install the fresh download. Your settings and extensions are stored separately in ~/.cursor/ and won't be wiped.

After reinstalling, check that ~/.cursor/extensions/ permissions are correct:

ls -la ~/.cursor/
# All directories should be owned by your user, mode 755
chmod -R u+rwX ~/.cursor/

On corporate machines with antivirus, add ~/Library/Application Support/Cursor/ to your antivirus exclusion list. Do this before the next update cycle.

Prevention

Keep an eye on Cursor's process list after you close the main window. A quick pgrep -l cursor on macOS or Linux tells you immediately if background processes are still running. If cursor_crashpad_handler is a chronic problem, you can disable crash reporting in Cursor's settings under Telemetry, which typically kills that background process.

Don't install Cursor in locations where your user account doesn't have full write access. On macOS, the standard /Applications/ directory is fine for single-user machines. On shared machines or corporate setups where IT manages the machine, ask for the user-level install path (~/Applications/ on macOS) or request that Cursor be added to the managed software catalog.

Watch your disk space. The updater needs enough room to download the full package plus keep the old version around during the swap. Cursor 0.47 installs are around 400-500 MB, so you need at least a gigabyte free during an update. I keep a habit of checking df -h ~ before starting any tool update on machines that might be tight on space.

Set up a reminder to check Cursor's actual version number once a week rather than trusting the badge. Go to Cursor > About Cursor and verify the version matches what's current on cursor.sh. This catches silent update failures before they compound.

When the fix doesn't work

If you've done a full clean reinstall and the loop still happens, the issue is likely environment-specific. File a bug report at cursor.sh/issues with your OS version, Cursor version, and the contents of the log file at ~/Library/Logs/Cursor/main.log (macOS) or %APPDATA%\Cursor\logs\main.log (Windows). The logs almost always contain the actual error that the UI isn't surfacing.

For corporate environments where you genuinely can't fix the underlying permissions issue, consider pinning a specific Cursor version by downloading it from cursor.sh's release archive and disabling auto-update in settings. Less convenient, but it stops the loop entirely.

If updates keep breaking after multiple clean installs, Cursor's GitHub Discussions page is active and the team responds to environment-specific bugs. Search before posting since this exact loop has several existing threads.