`syspolicyd` file descriptor leak while assessing Cursor Helper causes Gatekeeper failures for unrelated apps

[k14lb3]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After using Cursor for some time, macOS repeatedly prompts that Cursor wants to install or enable its Helper Plugin. Eventually, macOS begins failing Gatekeeper security assessments for unrelated applications, causing:

• Legitimate DMGs to report: “filename.dmg” is damaged and can’t be opened. You should move it to the Trash.
• Applications failing to launch, becoming extremely slow to open, or unexpectedly terminating during launch.
• The issue affecting applications completely unrelated to Cursor.

The affected files are not actually corrupted or damaged:

• hdiutil verify reports valid checksums on the DMGs.
• hdiutil attach successfully mounts the affected DMGs.
• Restarting syspolicyd immediately restores normal behavior for all previously-affected apps and DMGs.

Root Cause (as far as investigated)

syspolicyd (the macOS Gatekeeper daemon) was found holding an abnormally high number of open file descriptors — the vast majority pointing to the same executable:

/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app/Contents/MacOS/Cursor Helper (Plugin)

macOS logs during the failure period repeatedly showed:

• UNIX error exception: 24 (EMFILE— “Too many open files”)
• Failed to generate SecStaticCode

This strongly suggests syspolicyd is leaking file descriptors while repeatedly assessing the Cursor Helper (Plugin), eventually hitting the per-process open-file limit. Once that happens, Gatekeeper can no longer generate SecStaticCode for any app it’s asked to assess — which is why unrelated, valid DMGs get misreported as “damaged.”

It is not yet confirmed whether the leak originates from:

1. Cursor (e.g., the Helper Plugin re-triggering assessment prompts/checks repeatedly),
2. macOS’s syspolicyd (failing to release descriptors after assessment), or
3. An interaction between the two.

What is confirmed is that the descriptors accumulating on syspolicyd correlate directly with Cursor Helper (Plugin), and that restarting syspolicyd resolves the issue every time.

Steps to Reproduce

1. Install and use Cursor.

2. Repeatedly encounter the macOS prompt requesting permission to install/enable the Cursor Helper Plugin.

3. Continue using Cursor normally.

4. Eventually observe one or more of:

   • Legitimate DMGs reported as “damaged.”
   • Applications failing to launch.
   • Applications taking unusually long to open, or terminating unexpectedly during launch.

5. Inspect syspolicyd’s open file descriptors:

   sudo lsof -p $(pgrep syspolicyd) | wc -l
   

6. Observe a very high count (in this case ~2,572), with descriptor types breaking down as:

   sudo lsof -p $(pgrep syspolicyd) | awk '{print $5}' | sort | uniq -c
   

   → ~2,565 REG (regular file) descriptors, overwhelmingly pointing to Cursor Helper (Plugin).

7. Restart the daemon:

   sudo killall syspolicyd
   

   (macOS restarts it automatically.)

8. Re-check descriptor count — dropped to ~30 — and confirm previously-failing DMGs/apps now work normally.

Verification That Files Were Not Actually Corrupted

hdiutil verify ~/Downloads/"Firefox 153.0.dmg"
# → Checksum VALID

hdiutil attach ~/Downloads/"Firefox 153.0.dmg"
# → mounts successfully

xattr -l ~/Downloads/"Firefox 153.0.dmg"
# → nothing abnormal (quarantine attributes normal)

Expected Behavior

• Cursor Helper (Plugin) assessments should not cause syspolicyd to continuously accumulate file descriptors.
• syspolicyd should correctly release resources after each Gatekeeper assessment.
• Installing or using Cursor should not degrade Gatekeeper assessments for unrelated applications.

Screenshots / Screen Recordings

Operating System

macOS

Version Information

Version: 3.12.30
VS Code Extension API: 1.128.0
Commit: 63a2996a10d9e476b6c28e951dd7691d9c0cf480
Date: 2026-07-21T22:50:03.568Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the report. We don’t often get writeups this detailed, with an lsof breakdown and confirmation that the DMGs aren’t actually corrupted. That really helps.

You nailed the location. The FD leak itself is inside syspolicyd (Apple’s Gatekeeper system daemon), but it’s triggered by repeated reassessment of our Helper binary. So there are two sides here, and there’s something we can do on each.

What you can try right now:

1. Reset the daemon (you already found this, but sharing for completeness). It’s safe, macOS will restart it automatically:

   sudo killall syspolicyd
   

2. Remove the quarantine attribute from the app bundle. This often forces Gatekeeper to keep re-checking in a loop:

   sudo xattr -rd com.apple.quarantine /Applications/Cursor.app
   

3. If that doesn’t help, do a clean reinstall using a fresh DMG from Cursor · Download. That can refresh the app’s bundle state.

Since the FD leak is in syspolicyd, it’s worth filing the same report to Apple via Feedback Assistant. A well-behaved daemon shouldn’t leak file descriptors no matter what triggers it. That should speed up an OS-side fix.

Two questions so we can narrow down which macOS mechanism is getting restarted:

• Can you share the exact wording or a screenshot of the prompt about install/enable Helper Plugin? That’s not standard Cursor behavior, and it points to where the approval caching is breaking.
• And can you share the output of these commands on your machine:

  codesign -d --verbose=2 "/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app"
  spctl --assess -vvvv "/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app"
  

I’ve filed the issue internally. I can’t give an ETA yet, but if we get an update I’ll reply in the thread.

[k14lb3]

Thanks for the quick response!

Can you share the exact wording or a screenshot of the prompt about install/enable Helper Plugin? That’s not standard Cursor behavior, and it points to where the approval caching is breaking.

And can you share the output of these commands on your machine:

codesign -d --verbose=2 "/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app"
spctl --assess -vvvv "/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app"

[deanrie]

Thanks, both artifacts are exactly what we needed.

The codesign output confirms our theory. The helper is signed with Identifier=com.github.Electron.helper, which is the default Electron identifier, not the one expected for this bundle. At the same time, spctl --assess returns accepted, the signature is valid and notarized, so this isn’t a security issue. But this identity mismatch seems to prevent Gatekeeper from durably caching the assessment result, so every helper launch reruns a full assessment. While that happens, syspolicyd leaks file descriptors until it hits EMFILE.

The “Add Helper” prompt in the first screenshot is a separate mechanism. It’s shown by the updater installer when it tries to install a privileged helper tool, not the marketplace plugin and not the same plugin helper that Gatekeeper assesses. The fact it shows up again is another sign that macOS isn’t keeping the approval between runs. Most likely both symptoms share the same root cause in the helpers’ signing state.

I’ve reported all of this internally with your data. I can’t share an ETA for a fix yet. I’ll post an update in the thread when I have one. For now the existing workarounds still apply: sudo killall syspolicyd to reset it, and removing quarantine from the bundle. Also, it’d really help if you could report the fd leak to Apple via Feedback Assistant. The leak is inside syspolicyd, so an OS-side fix is needed too.

[k14lb3]

Also, it’d really help if you could report the fd leak to Apple via Feedback Assistant. The leak is inside syspolicyd, so an OS-side fix is needed too.

Reported it to Feedback Assistant. I also added a link to this thread for additional context.

Thanks!