Codex Desktop subagent fan-out contributed to WindowServer watchdog crash under memory pressure on 16 GB MacBook Air

Start with the parent and child session logs, then correlate their fan-out timeline with the WindowServer crash report, watchdog reports, and VMCOMPRESSOR_SPACE_SHORTAGE evidence. Investigate default concurrency, memory-pressure handling, and Electron/Chromium process footprint. Done means constrained-memory systems avoid unsafe fan-out or degrade gracefully without contributing to a WindowServer watchdog failure.

Summary

On a 16 GB Apple Silicon MacBook Air, a Codex Desktop session that spawned multiple subagents contributed to severe system-wide memory pressure and a WindowServer watchdog crash.

This did not appear to be a kernel panic or full machine reboot. Instead, macOS entered repeated JETSAM_REASON_MEMORY_VMCOMPRESSOR_SPACE_SHORTAGE, WindowServer became unresponsive, and the UI session effectively collapsed.

I am filing this because Codex Desktop should not be able to push a normal 16 GB Apple Silicon machine into a state where WindowServer dies during routine multi-agent review work.

Environment

• Hardware: MacBook Air Mac16,13
• RAM: 16 GB
• OS: macOS 26.5.2 (25F84)
• Date: July 22, 2026
• Codex Desktop session ID: 019f884a-867b-77d0-b680-236415b27ca0

What happened

• I was using Codex Desktop for PR review work.
• The session spawned 5 subagents in parallel.
• The machine started asking me to force quit apps.
• Even after force quitting apps, the system still appeared to crash/restart.
• Investigation afterward showed this was a WindowServer watchdog failure under severe memory pressure.

Subagent timeline

The parent session spawned 5 subagents at these times:

• 2026-07-22T05:29:37.777Z
• 2026-07-22T05:29:42.612Z
• 2026-07-22T05:30:09.635Z
• 2026-07-22T05:30:47.995Z
• 2026-07-22T05:36:14.772Z

This was a real multi-agent fan-out workload, not a single lightweight helper.

System evidence

From macOS logs around the failure window:

• repeated JETSAM_REASON_MEMORY_VMCOMPRESSOR_SPACE_SHORTAGE
• WindowServer timed out transactions
• delayed WindowServer timers
• launchd recorded WindowServer exit due to watchdog with unresponsive work processor(s): WindowServer main thread

From the WindowServer crash report:

• termination namespace: WATCHDOG
• indicator: monitoring timed out for service
• detail: WindowServer initialization not complete (post IOKitWaitQuiet)
• detail: 93 seconds since last successful checkin

Memory footprint observed in the crash stackshot

Codex / ChatGPT family processes captured in the crash report included approximately:

• Codex (Renderer): ~818 MB
• Codex (Service): ~390 MB
• codex: ~733 MB
• additional codex processes: ~104 MB, ~65 MB, ~31 MB
• ChatGPT: ~472 MB

Chrome family processes were also heavy at the same time, including approximately:

• Google Chrome: ~447 MB
• one Google Chrome Helper: ~778 MB
• multiple Chrome renderers at ~1.13 GB, ~491 MB, ~488 MB, ~445 MB, ~434 MB, ~372 MB, ~362 MB, ~359 MB, and more

So this looks like a combined Chromium/Electron memory pile-up, but Codex Desktop was a meaningful contributor and the subagent fan-out clearly increased memory pressure.

Important note

This does not look like "Codex alone used all memory."

It does look like:

1. Codex Desktop spawned a fairly aggressive multi-agent workload.
2. On a 16 GB machine, that materially increased memory pressure.
3. Under combined pressure from Codex + Chrome-family processes, macOS ran out of compressor headroom.
4. WindowServer then stalled and was watchdog-killed.

That is still a Codex product issue worth addressing, because the tool should degrade more safely on constrained RAM rather than helping push the desktop into an unrecoverable UI failure.

Expected behavior

• Codex Desktop should be more conservative with subagent fan-out on 16 GB machines.
• It should detect or respect system memory pressure before spawning more concurrent agent processes.
• It should fail more gracefully than contributing to a WindowServer watchdog crash.

Suggested areas to investigate

• default subagent concurrency on lower-memory systems
• memory-pressure-aware throttling before spawning additional agents
• Electron/Chromium renderer and service process footprint during multi-agent sessions
• whether Desktop can surface a warning or auto-serialize agent work when memory pressure becomes high

Available supporting artifacts

I have the following available if needed:

• parent Codex session log
• child session logs for all spawned subagents
• WindowServer crash report
• WindowServer watchdog spin reports
• extracted log timeline showing VMCOMPRESSOR_SPACE_SHORTAGE