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.777Z2026-07-22T05:29:42.612Z2026-07-22T05:30:09.635Z2026-07-22T05:30:47.995Z2026-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 MBCodex (Service): ~390 MBcodex: ~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:
- Codex Desktop spawned a fairly aggressive multi-agent workload.
- On a 16 GB machine, that materially increased memory pressure.
- Under combined pressure from Codex + Chrome-family processes, macOS ran out of compressor headroom.
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 reportWindowServer watchdog spin reports- extracted log timeline showing
VMCOMPRESSOR_SPACE_SHORTAGE
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
WindowServerwatchdog crash.This did not appear to be a kernel panic or full machine reboot. Instead, macOS entered repeated
JETSAM_REASON_MEMORY_VMCOMPRESSOR_SPACE_SHORTAGE,WindowServerbecame 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
WindowServerdies during routine multi-agent review work.Environment
Mac16,1325F84)019f884a-867b-77d0-b680-236415b27ca0What happened
WindowServerwatchdog failure under severe memory pressure.Subagent timeline
The parent session spawned 5 subagents at these times:
2026-07-22T05:29:37.777Z2026-07-22T05:29:42.612Z2026-07-22T05:30:09.635Z2026-07-22T05:30:47.995Z2026-07-22T05:36:14.772ZThis was a real multi-agent fan-out workload, not a single lightweight helper.
System evidence
From macOS logs around the failure window:
JETSAM_REASON_MEMORY_VMCOMPRESSOR_SPACE_SHORTAGEWindowServertimed out transactionsWindowServertimerslaunchdrecordedWindowServerexit due to watchdog withunresponsive work processor(s): WindowServer main threadFrom the
WindowServercrash report:WATCHDOGmonitoring timed out for serviceWindowServer initialization not complete (post IOKitWaitQuiet)93 seconds since last successful checkinMemory footprint observed in the crash stackshot
Codex / ChatGPT family processes captured in the crash report included approximately:
Codex (Renderer): ~818 MBCodex (Service): ~390 MBcodex: ~733 MBcodexprocesses: ~104 MB, ~65 MB, ~31 MBChatGPT: ~472 MBChrome family processes were also heavy at the same time, including approximately:
Google Chrome: ~447 MBGoogle Chrome Helper: ~778 MBSo 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:
WindowServerthen 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
WindowServerwatchdog crash.Suggested areas to investigate
Available supporting artifacts
I have the following available if needed:
WindowServercrash reportWindowServerwatchdog spin reportsVMCOMPRESSOR_SPACE_SHORTAGE