codex app-server saturates macOS syspolicyd, hanging the terminal

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

26.422.30944 (2080)

What subscription do you have?

Pro ($200/mo)

What platform is your computer?

Darwin 25.2.0 arm64 arm

What issue are you seeing?

On macOS, the codex app-server process fork-execs the bundled node helper (Codex.app/Contents/Resources/node_repl) at ~250 per second while working with six subagents. Because that helper does not pass macOS's expected validation category, every exec triggers a full Gatekeeper crypto check. Within a few hours of running Codex, syspolicyd saturates a CPU core, every new shell command stalls for several seconds (zsh interactive startup goes from sub-second to 4+ minutes), and Apple emits the warning "This will likely result in a block in the future."

Evidence:

2026-04-27 15:27:45.203127-0400  syspolicyd: [com.apple.syspolicy.exec:default] <private> with PID 29375 violates validation category policy. This will likely result in a block in the future
2026-04-27 15:27:45.207037-0400  syspolicyd: [com.apple.syspolicy.exec:default] <private> with PID 29376 violates validation category policy. This will likely result in a block in the future
2026-04-27 15:27:45.210908-0400  syspolicyd: [com.apple.syspolicy.exec:default] <private> with PID 29377 violates validation category policy. This will likely result in a block in the future
... (sequential PIDs continue at ~250/sec)

 $ ps -p 53907 -o pid,ppid,etime,command
  PID  PPID     ELAPSED COMMAND
53907 52783    01:22:43 /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

$ # racing capture of children:
30413 53907 node

Quitting Codex immediately ends the violation stream; reopening Codex restarts it. Killing only the codex app-server PID stops the issue until Codex respawns it.

Why this matters beyond performance: Apple's log message ("This will likely result in a block in the future") indicates a future macOS update will outright block these execs, breaking Codex on macOS for all users.

Suggested fix: Either (a) ship a properly Developer-ID-signed, notarized, hardened-runtime helper binary at Contents/Resources/node_repl, or (b) replace fork-exec of the helper with an in-process or persistent-worker pattern so the validation cost is paid once instead of per-call.

What steps can reproduce the bug?

Reproduction:

1. macOS [version], Codex [version].
2. Launch Codex, work for multiple hours, especially with multiple subagents on a project.
3. In any terminal: time zsh -i -c exit — observe wall time of multiple minutes.
4. ps aux | sort -k3 -rn | head — syspolicyd ~80% CPU, trustd ~20% CPU.

What is the expected behavior?

Running Codex should not noticeably impact system-wide performance. Specifically:

1. The bundled node_repl helper should be a properly Developer-ID-signed, notarized, hardened-runtime binary so that macOS's syspolicyd can cache its validation result on first execution and skip full crypto verification on subsequent execs.
2. syspolicyd and trustd CPU usage should remain at idle baseline (typically <5%) while Codex is running, regardless of how long it has been open.
3. macOS should not log "violates validation category policy. This will likely result in a block in the future" for any binary Codex ships or invokes.
4. Unrelated terminal sessions and shell commands should remain responsive — time zsh -i -c exit should complete in well under a second, the same as before Codex was launched.

Additional information

I didn't attempt to replicate this with the codex CLI, but using OpenCode, having GPT-5.5 Fast do work is blazing fast compared to within the Codex desktop app (in the realm of ~20x faster for me, a code review went from taking 40 minutes+ to 2-3 minutes)