Codex Desktop app-server leaks child processes and writes excessive logs after crash/restart

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

• #25744
• #26843
• #26374
• #26795
• #26773

Powered by Codex Action

Additional recurrence: this happened a third time on 2026-06-07 after another restart. Post-restart checks again did not point to memory pressure: no swap/compressor pressure and the internal SSD reported SMART Verified with about 60 GiB free. The recurring signal remains launch/process pressure around Codex Desktop: very large syspolicyd validation bursts during/after restart, Codex app-server validation warnings, prior Codex CLI diagnostic reports showing multi-GB disk writes in minutes, and stale process-manager records not matching live OS PIDs. I installed a local low-overhead guard to capture future recurrence metrics without attaching raw logs. Raw local logs still appear privacy-sensitive and are not being shared publicly.

Additional evidence from another recurrence on 2026-06-07 around 03:14 PDT: a local guard captured 7 Codex app-server processes and 14 direct children shortly before the restart, plus a fresh Codex diagnostic. /Library/Logs/DiagnosticReports/codex_2026-06-07-031212_*.diag reports Codex PID 18723 dirtied 2147.48 MB over 254 seconds, with the heaviest stack in pwrite. A 10-second unified-log slice from 03:10:00-03:10:10 contained 3166 syspolicyd dispatch_mig_server returned entries and 3168 validation-category-policy entries for rapidly changing PIDs. Shutdown stall collection at 03:14 captured Codex browser_crashpad_handler processes, consistent with Codex crashing/restarting during the degraded state. Firefox appeared to hang/crash from the user's perspective, but no fresh Firefox diagnostic report was produced after 03:10, so it looks like collateral launch/system degradation rather than an independent Firefox crash. Raw logs are still not being attached because they contain local/private context.

Additional evidence from a macOS launch/input freeze investigation (sanitized, no prompt/log payloads):

• Environment: macOS 26.3. Symptom: after reboot, third-party/non-system app launches could hang indefinitely while existing system apps still partly worked. Firefox bounced in Dock; Terminal/shell-launched non-system runtimes also stalled; Codex UI/app-server stayed alive enough to continue some work.
• The system-level failure mode was non-system executable launch assessment stalling before program startup. A sampled Codex child process was a bundled runtime python3 under ~/.cache/codex-runtimes/... with a tiny RSS footprint and its stack entirely at _dyld_start.
• Reproduced outside Codex parent context: a one-shot launchctl submit job running a copied Codex node binary stayed in launch/running state instead of exiting immediately. Apple-signed system binaries like /usr/bin/true and /bin/mkdir still launched quickly. This points to macOS syspolicy/dyld/provenance assessment under load, not a Python/Node script bug.
• During the bad window, syspolicyd was hot for long periods and the system accumulated many tiny pre-main or zombie children. Codex app-server was a major amplifier: it had dozens of direct child processes (rg, node_repl, bundled runtime Python/Node, Computer Use helper) stuck with very small RSS. Firefox also accumulated plugin-container zombies.
• Codex local process-manager state contained about 196 remembered tool records, many from old chats/repos, mostly rg. Only a few remembered PIDs were live, so this did not look like a simple relaunch queue, but it is a strong signal that Codex should prune/reconcile stale tool-process state and avoid child-launch storms after reboot or after launch failures.
• The local root cause had multiple non-Codex producers too: stale launch agents were crash-looping/misconfigured, including Node helpers pointed at missing files and stale app-start launchers. After removing/repairing those launch agents and letting the backlog drain, syspolicyd returned near idle and Codex/Homebrew Node launch latency returned to ~0.05s in quiet samples.

Codex-specific recommendation: add backpressure/timeouts around app-server child launches on macOS when children remain tiny and stuck at _dyld_start; aggressively reap/kill and mark failed rather than continuing to spawn; prune stale ~/.codex/process_manager/chat_processes.json records; and avoid repeated Computer Use/helper launches while syspolicy validation is saturated. Codex was not the only root cause in this incident, but it amplified the system-wide launch wedge enough that the whole GUI/input session became unrecoverable without a reboot.

Follow-up evidence from a later recurrence on macOS (2026-06-07 around 22:24-22:25 PT), sanitized to avoid raw prompts/payloads:

• syspolicyd repeatedly sat around ~51-53% CPU while Codex-launched child processes remained at extremely low RSS (typically 32 KB), consistent with being stuck pre-main / before interpreter startup.
• Live examples included Codex child jobs such as Homebrew Node/npm, node ... prettier --check ..., rg ..., and short shell helpers. The parent of the live stuck children was /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled.
• Unified log during the same window showed a flood of com.apple.Gatekeeper.PolicyViolation telemetry from syspolicyd, com.apple.syspolicy.exec messages with dispatch_mig_server returned 268435459, and messages of the form PID ... violates validation category policy. This will likely result in a block in the future. macOS privacy redacted the executable path in the log, but simultaneous ps output tied the active low-RSS launch queue to Codex app-server descendants.
• System binaries continued to launch normally while non-system developer tool/app-bundle launches queued or wedged. In bad cases this escalated to Firefox/app launches bouncing forever and user input/app startup appearing globally broken until reboot.

This points to Codex Desktop needing backpressure/reuse/throttling around child process launches and/or explicit detection of macOS launch-assessment saturation (syspolicyd / syspolicy.exec) so it stops scheduling more non-system executable launches while the OS launch path is wedged. Raw command payloads are intentionally omitted because they can include user prompt text and local paths.

Cross-linking related reports that look like the same or adjacent failure domain. I’m not claiming they all have one root cause, but they point at the same macOS launch-assessment / signing / helper-process pressure area:

• #25719 — Codex Desktop for macOS repeatedly triggers syspolicyd / trustd CPU and memory runaway. This looks closest to the system-wide app-launch failure pattern reported here.
• #23649 — un-notarized macOS Codex CLI binaries causing syspolicyd / XProtect scanning storms when spawned repeatedly. This is relevant because the observed failure here also correlates with repeated non-system executable launches and syspolicyd saturation.
• #21008 — Codex Desktop leaking orphaned MCP helper processes under launchd. Related because leaked or repeated helpers increase the launch/assessment/process pressure that can make the macOS failure mode much worse.
• #20349 — duplicate MCP/helper process trees and multi-GB RSS during UI/debugging workflows. Same helper-process accumulation class, even if the primary symptom is memory/process pressure rather than launch assessment.
• #21200 — SkyComputerUseClient SIGKILL / code-signature invalid when launched outside the expected app process tree. Relevant because this report captured SkyComputerUseClient/Computer Use helper launches in the same incident family, and signing/launch constraints appear to be involved.
• #24207 — Computer Use helper signing/Gatekeeper validation errors on macOS Intel. Adjacent signing/entitlement/Gatekeeper surface for the bundled native helper.
• #18523 — Codex.app code-signature verification failures across versions. Potentially related to the same macOS assessment path, especially if validation results are not stable/cacheable.
• #5787 — older macOS quarantine/notarization issue for the Codex binary. Older, but still relevant background on Codex binaries interacting badly with macOS quarantine/notarization.

The common engineering hypothesis from this report plus those threads: Codex Desktop should apply backpressure/reuse/throttling around spawned helpers and tool-server processes, and should detect when macOS launch assessment (syspolicyd / syspolicy.exec / trust validation) is saturated before scheduling more non-system executable launches. It would also help to verify notarization/signing/caching behavior for all shipped helper binaries, especially Computer Use / SkyComputerUseClient and CLI/runtime binaries that may be spawned repeatedly.

Follow-up with a more specific recovery experiment from the 2026-06-08 recurrence, again sanitized to avoid prompt text or local command payloads:

• During the incident, Apple-signed system binaries (/usr/bin/true, /bin/ls) launched immediately, while a Codex-bundled helper launch (/Applications/Codex.app/Contents/Resources/node_repl --version) hung. That narrowed the failure to non-system executable launch assessment rather than global CPU, disk, or shell failure.
• The Codex app-server process had a large descendant tree at the time, including many tiny low-RSS children stuck before useful startup. Examples included Codex-bundled helpers, Node helper launches, rg, Playwright/Chromium helpers, and site-status/build helpers launched through active Codex work.
• I terminated only stale low-RSS pre-main Codex-descended children, leaving the Codex app/server itself running. Within about 30 seconds, syspolicyd CPU dropped from roughly 56% to under 1%, and the count of Codex low-RSS stuck children fell to zero. No reboot and no Codex quit was needed for that observed drain.
• Active Codex automations were checked: the daily automation was not firing during this 01:xx local incident, and the hourly automation was paused. The trigger looked like normal concurrent interactive Codex workload fanout rather than a scheduled automation.

This is stronger evidence that Codex Desktop needs a macOS launch-assessment backpressure mechanism, not only orphan cleanup after the fact: if spawned children remain tiny/pre-main or syspolicy validation is hot, Codex should stop scheduling more non-system executable launches, reuse existing helper processes where possible, and aggressively fail/reap the stuck child jobs instead of continuing to fan out.

Additional live incident evidence from 2026-06-10 ~20:00 PDT:

• User-visible symptom: Firefox pages spun forever / app launches stalled while Codex itself could still run existing tool sessions.
• syspolicyd was repeatedly at ~53-67% CPU while many newly launched non-system helpers sat at ~32 KB RSS, apparently pre-main / blocked in launch assessment.
• Producers observed during the incident included Codex app-server child helpers (rg, node/node_repl, Computer Use completion helpers), Firefox plugin-container launches, and a local Headquarters deployment automation fanout (auto-template, publish-status/site-status, and auto-push/publish helpers).
• Terminating stuck helper leaves alone reduced the 32 KB queue but did not recover the system while producers kept respawning. Restarting syspolicyd while fanout continued also immediately re-saturated it.
• The reliable recovery sequence was: stop/kill the fanout producers, archive active background Codex threads, clear stuck helper leaves, then admin-restart syspolicyd. After that: syspolicyd returned to 0.0% CPU and the low-RSS stuck queue went to zero.
• An admin sample of the hot syspolicyd process showed the active path under syspolicyd.executions.mig in Security.framework code-signing verification, especially SecCodeCopySigningInformation, Security::CodeSigning::SecStaticCode::signingInformation, validateDirectory, CMSDecoderCopySignerStatus, and timestamp/cert parsing (decodeTimeStampTokenWithPolicy). This supports the diagnosis that the stall is launch/code-signing assessment saturation, not DNS/network/SSD/memory pressure.

Local mitigation added on my side: I throttled one local app's background publish/status fanout and added a macOS launch-pressure guard so it defers passive automation when syspolicyd CPU or 32 KB launch-stall counts are high. That helps reduce one producer, but Codex still appears able to create the same pressure via multiple active/background threads and completion/helper launches.

Independent reproduction on Intel macOS — same disk-write/log signature, escalating to a full WindowServer watchdog kill (whole-screen freeze)

Corroborating this on different hardware and a much newer build. Same 2147 MB … pwrite disk-write signature and TRACE-dominated logs_2.sqlite, but here it escalated past "launches stall" to a WindowServer userspace_watchdog_timeout — the entire screen froze, twice in one day.

Environment

• Codex Desktop 26.623.70822 (CFBundleVersion 4559) — newer than the 3593 above, so the behavior persists in current builds
• Codex Framework 149.0.7827.197; binary under load …/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
• MacBookPro16,2, Intel x86_64, 8 logical CPUs, 16 GB — the reports here so far are Apple Silicon; this widens scope to Intel
• macOS 26.5.1 (25F80), SIP enabled

What macOS recorded

1. codex_<ts>.diag — Event: disk writes, 2147.48 MB dirtied over 8825 s (~243 KB/s, ~10× the limit). Heaviest stack is SQLite WAL churn: sqlite3_exec → sqlite3_step → sqlite3_wal_checkpoint_v2 → pwrite (via sqlx_sqlite). ~/.codex/logs_2.sqlite was 301 MB / 80,685 rows, 71% TRACE (57k TRACE / 14k INFO / 8k DEBUG vs 1.2k WARN / 20 ERROR) over a 10-day span — overwhelmingly trace-logging write amplification, matching the codex_otel.trace_safe / *.log_only targets noted above.
2. Two concurrent codex app-server instances at freeze time, one orphaned to launchd (PPID 1) since ~7 h earlier, never reaped, still holding logs_2.sqlite open and writing. ~38 Codex-owned processes / ~1.3 GB RSS incl. accumulated cua_node/node_repl + mcp-server children (matches #25744).
3. WindowServer userspace_watchdog_timeout → whole-screen freeze (the new/worse symptom). The spindump shows WindowServer was not CPU-spinning: its main thread used 0.2 s CPU over the 5.57 s watchdog window and was blocked in mach_msg the whole time (SkyLight → … → mach_msg_trap), CoreDisplay likewise blocked. Reason: WindowServer returned not alive … Display … not ready … Surface Use Counts: 2(1) 10(3) 11(1). It was starved, not buggy — it could not get a timely reply while the run queue was saturated. In the same stackshot the top CPU consumers were syspolicyd (3.0 s, in com.apple.security.syspolicy.yara / XProtect) and trustd (1.2 s) — consistent with #25719, driven by the constant new-process launches. Load average ≈ 470, ≈ 105 MB free RAM at that instant.

So the separately-filed symptoms look like one chain on a memory-constrained Mac: app-server child/log leak (this issue) + CUA/MCP accumulation (#25744) saturate CPU/RAM/disk → syspolicyd/trustd spike (#25719) → WindowServer misses its watchdog deadline → it gets killed → full-screen freeze.

Mitigations that worked here (until the next session): kill the orphaned app-server; prune old logs rows + VACUUM (301 → 110 MB); restart Codex (collapses 38 → 14 processes, 2 → 1 app-server). A user-facing toggle to disable --analytics-default-enabled or a size cap on logs_2.sqlite would remove the disk-write driver. Redacted .spin / .diag headers available on request.

Confirming this on Windows 11 (build 26200, 32 GB RAM), Codex Desktop 26.623.9142.0 — same helper-stack accumulation described here.
What I saw (matches this issue):
• Under the codex.exe app-server, ~21 node.exe ./mcp/server.mjs --stdio / server.bundle.mjs children (~52–54 MB each) plus accumulating node_repl.exe (computer-use), holding ~1.1 GB and climbing.
• The burst correlated exactly with 3 long computer-use sessions left open for hours (per-session ~510k / 579k / 732k tokens).
Two extra data points that may help the fix:

1. Re-leak after surgical cleanup: killing just the node children while leaving the app-server alive is not sufficient — fresh mcp/server.mjs children (new PIDs) respawn under the same app-server within minutes. Only terminating the entire Codex app process tree stops it.
2. Not user-MCP-config-related: my only configured MCP server is a remote HTTP endpoint (spawns no subprocess); the leaking mcp/server.mjs processes are app-internal, so this is Codex’s own child-process lifecycle, independent of user MCP config.

Repro: long/concurrent computer-use sessions left open → node_repl + internal mcp/server.mjs children accumulate and are not reaped on turn/session completion.
Requested: reap (or pool+reuse) internal MCP-server + node_repl children on turn/session completion, with a cap + idle reclamation, so long/multi-session use doesn’t leak host processes. Happy to provide a process-tree snapshot if useful.