Codex triggers syspolicyd file descriptor leak on macOS, causing all DMG files to be reported as “damaged”

Open 💬 3 comments Opened Jun 4, 2026 by myxtype
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.601.21317

What subscription do you have?

Plus

What platform is your computer?

macOS 26.5.1 (Build 25F80)

What issue are you seeing?

After launching Codex and using it for a while:

  • Any DMG file downloaded from official websites starts showing:

“.dmg is damaged and can’t be opened. You should move it to the Trash.”

  • This affects multiple unrelated applications (VS Code, Chrome, etc.).
  • Restarting macOS temporarily fixes the issue.
  • After Codex runs for some time, the issue comes back.

What steps can reproduce the bug?

Hi,

I’m experiencing a serious issue on macOS that appears to be related to Codex.

Environment

  • macOS 26.5.1 (Build 25F80)
  • Apple Silicon (MacBook Air)
  • Codex downloaded from the official website
  • Fresh reinstall of Codex (issue persists after reinstall)

Symptoms

After launching Codex and using it for a while:

  • Any DMG file downloaded from official websites starts showing:

“.dmg is damaged and can’t be opened. You should move it to the Trash.”

  • This affects multiple unrelated applications (VS Code, Chrome, etc.).
  • Restarting macOS temporarily fixes the issue.
  • After Codex runs for some time, the issue comes back.

Investigation

I verified that the DMG files themselves are not corrupted:

hdiutil verify VSCode-darwin-arm64.dmg

Verification succeeds.

I also found that spctl eventually starts failing with:

spctl -a -vv VSCode-darwin-arm64.dmg

Output:

spctl: Too many open files

The most interesting finding is that syspolicyd continuously accumulates file descriptors pointing to Codex.

Immediately after restarting syspolicyd:

sudo lsof -p $(pgrep syspolicyd | head -1) | \
awk '{print $9}' | sort | uniq -c | sort -nr | head

Output is normal.

After running Codex:

720 /Applications/Codex.app/Contents/MacOS/Codex
1907 /Applications/Codex.app/Contents/MacOS/Codex
2015 /Applications/Codex.app/Contents/MacOS/Codex
2222 /Applications/Codex.app/Contents/MacOS/Codex

The count keeps increasing over time.

Example:

2222 /Applications/Codex.app/Contents/MacOS/Codex

Almost all open descriptors inside syspolicyd are associated with the Codex executable.

Additional observation

If I completely quit Codex:

  1. sudo killall syspolicyd
  2. Wait for macOS to restart syspolicyd

The file descriptor count returns to normal and DMG files can be opened again.

If I launch Codex again, the descriptor count starts growing and eventually the “damaged DMG” problem returns.

Expected behavior

Launching Codex should not cause syspolicyd to continuously accumulate references to the Codex executable or eventually break Gatekeeper verification for unrelated applications.

Question

Has anyone seen similar behavior?

Is there a known issue between Codex and Gatekeeper (syspolicyd) on recent macOS versions?

I’m happy to provide additional logs or run diagnostic commands if needed.

Thanks.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #25882
  • #25243
  • #25719
  • #26117

Powered by Codex Action

guidedways contributor · 2 months ago
omarpinarecords · 2 months ago

Cross-linking a related in-app report: Feedback ID 019ed2cb-eea6-7851-be4d-8be66a992d92.

I also added the fuller diagnostic note here: https://github.com/openai/codex/issues/27662#issuecomment-4724737107

Same local symptom family on macOS 26.5.1 build 25F80: macOS showed "openai" is damaged and can’t be opened, while spctl failed even for /bin/ls with internal error in Code Signing subsystem. The OpenAI Homebrew CLI still ran from Terminal and was signed by OpenAI, so this looked like a broader Gatekeeper/SystemPolicy broken state rather than a corrupt file.