# Bug Report: Cursor 3.6.31 crashes on launch — Electron Framework code signature invalidated after auto-update

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After an auto-update, Cursor fails to launch. dyld aborts at startup because the app-level code signature is invalid, so Gatekeeper denies loading the Electron Framework. This is a code-signing integrity issue introduced by the auto-update process, not a user/quarantine problem.

Environment

  • Cursor: 3.6.31 (build 3.6.31)
  • Bundle ID: com.todesktop.230313mzl4w4u92 (Team VDXQ22DGB9)
  • macOS: 26.5.1 (25F80)
  • Hardware: MacBookPro18,3 (Apple Silicon, arm64)
  • SIP: enabled · developerMode: 1
  • Install: manual .dmg (not Homebrew)

Crash signature

Exception Type:   EXC_CRASH (SIGABRT)
Termination Reason: Namespace DYLD, Code 1, Library missing
Library not loaded: @rpath/Electron Framework.framework/Electron Framework
Reason: ... code signature ... not valid for use in process:
        library load denied by system policy
codeSigningTrustLevel: 4294967295 (-1)
fatalDyldError: 1

Diagnosis (what we found)

  • codesign -v /Applications/Cursor.app → fails (app-level signature broken)
  • spctl -a -t exec -vvv → bundle format unrecognized, invalid, or unsuitable
  • codesign -vvv on the inner Electron Framework.framework → reports valid on disk / satisfies its Designated Requirement
  • → So the outer .app bundle signature/seal is the corrupted part, while the nested framework signature is intact. Strongly suggests the auto-updater wrote the bundle without correctly re-sealing the top-level signature.
  • No com.apple.quarantine xattr (only com.apple.macl), so this is not a Gatekeeper-quarantine prompt issue.

Steps to reproduce

  1. Run Cursor 3.6.31 on macOS 26.5.1 (Apple Silicon).
  2. Let the in-app auto-update apply.
  3. Relaunch → instant crash (SIGABRT, DYLD library missing) on every launch.

Workaround that fixed it

Reinstalling the full app restores a valid signature:

brew install --cask cursor --force
# or re-download the .dmg from cursor.com and replace /Applications/Cursor.app

(Re-running the same version is enough — the issue is the broken seal, not the version.)

Suspected root cause / ask

The auto-updater appears to replace app contents without re-sealing / re-signing the top-level .app bundle, leaving codesign -v invalid and Gatekeeper refusing to load frameworks under hardened-runtime + library-validation policy. Please verify the updater re-seals the bundle signature after applying an update on macOS 26.x.

Attachments

  • Full .ips crash reports available at: ~/Library/Logs/DiagnosticReports/Cursor-2026-06-03-09*.ips

Steps to Reproduce

  1. Run Cursor 3.6.31 on macOS 26.5.1 (Apple Silicon, SIP enabled).
  2. Let the in-app auto-update apply, then quit Cursor.
  3. Relaunch Cursor → it crashes instantly on every launch (SIGABRT).

Crash: dyld “Library not loaded: @rpath/Electron Framework.framework/
Electron Framework — code signature not valid for use in process:
library load denied by system policy”.

Verified codesign -v /Applications/Cursor.app FAILS (app-level
signature broken) while the inner Electron Framework signature is still
valid → the auto-updater left the top-level .app bundle unsigned/unsealed.

Workaround: full reinstall (brew install --cask cursor --force or
re-download the .dmg) restores a valid signature and it launches fine.

Operating System

MacOS

Version Information

  • Cursor: 3.6.31 (build 3.6.31)

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Thanks for the detailed diagnosis. You’re right that this is a code signature integrity issue, not a Gatekeeper quarantine problem. We’ve seen the same SQRLCodeSignatureErrorDomain / “invalid signature” error internally from the Squirrel updater. Our team is aware and tracking this.

Your workaround is correct: a full reinstall (either brew install --cask cursor --force or re-downloading the DMG from cursor.com) restores a valid signature. Re-running the same version is enough since the issue is the broken seal, not the version itself.