Cursor 3.11.25 child processes killed with “Code Signature Invalid” on macOS 26.5.2

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor repeatedly generates macOS crash reports shortly after launch. The main process may start, but a child process launched from /Applications/Cursor.app/Contents/MacOS/Cursor is killed by macOS taskgated with EXC_CRASH (SIGKILL), Namespace CODESIGNING, Code 1, “Taskgated Invalid Signature”. This continues after reinstalling Cursor from a fresh official download.

Steps to Reproduce

  1. Install the official Apple Silicon build of Cursor 3.11.25 on macOS 26.5.2.
  2. Move Cursor.app to /Applications and launch it normally.
  3. Within a few seconds, macOS creates a Cursor crash report for a child Cursor process.
  4. The crash consistently reports: SIGKILL (Code Signature Invalid) / Taskgated Invalid Signature.
  5. Reinstalling the application does not resolve the issue.

Expected Behavior

Cursor and all of its child processes should launch normally without being rejected by macOS code-signing enforcement.

Operating System

MacOS

Version Information

Cursor: 3.11.25 (Apple Silicon / ARM64)
macOS: 26.5.2 (build 25F84)
Hardware: Apple Silicon, Mac17,9 (Apple M5 Pro)

For AI issues: which model did you use?

N/A — application startup / code-signing issue

For AI issues: add Request ID with privacy disabled

N/A — failure occurs during application startup

Additional Information

The affected process is a child Cursor process whose parent/responsible process is Cursor. SIP is enabled. The crash report shows codeSigningID and codeSigningTeamID as empty for the killed process. However, running codesign --verify --deep --strict /Applications/Cursor.app reports that the app is valid on disk and satisfies its designated requirement, and spctl --assess --type execute reports “accepted” with source “Notarized Developer ID”. Multiple crash reports are generated across repeated launches. This started after updating macOS, so it may be an incompatibility between Cursor 3.11.25/Electron and code-signing enforcement in macOS 26.5.2.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report, there’s an important clue here. The fact that codesign --verify --deep --strict and spctl --assess pass means the Cursor app bundle on disk is signed correctly. The child process is getting killed at the macOS kernel level (taskgated), with empty codeSigningID and codeSigningTeamID. That points to enforcement by macOS or third party software, not a broken signature.

A similar case was discussed here: [macOS 27] cursor CLI killed with SIGKILL (Taskgated Invalid Signature) — ELECTRON_RUN_AS_NODE blocked. In that thread, the cause was third party security, antivirus, or EDR software doing runtime injection into the Cursor process, and then taskgated kills the child. Please check a few things in order:

  1. Update Cursor. 3.11.25 is behind the current 3.12.x line, and newer builds include mitigations for macOS 26. Download from Cursor · Download.
  2. Check if you have any third party security, antivirus, or EDR software that injects into processes. Add Cursor to the allowlist or temporarily disable it and test again. This was a confirmed cause in the similar thread.
  3. Reset quarantine attributes: xattr -cr /Applications/Cursor.app. Note: com.apple.provenance is protected by SIP and you can’t remove it with a normal xattr -d, so don’t rely on that. Focus on step 2.
  4. If it still doesn’t help, do a clean reinstall. Delete /Applications/Cursor.app, then install a fresh build from the website. Important: don’t use Migration Assistant.

If it still gets killed after this, please share the Process, Path, and Responsible Process fields from the crash report so we can see which child is failing. Also let me know if you launch Cursor from a non Apple terminal like Ghostty. In the similar case, launching from Ghostty affected the result, so it’s an important detail.