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

Open 💬 2 comments Opened Jul 22, 2026 by mohitsbsftester

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

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 report
WindowServer watchdog spin reports
extracted log timeline showing VMCOMPRESSOR_SPACE_SHORTAGE

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

#34606

Powered by Codex Action

gengenzhu · 3 days ago

Related macOS memory-pressure incident

I had a very similar incident on a 16 GB Apple Silicon Mac while using Codex for local figure-generation work.

At around 05:43, macOS recorded a Jetsam event caused by vm-compressor-space-shortage. Only about 242 MiB of memory was genuinely free. WeChat was using roughly 4.5 GiB, and there were also many Python and Chrome processes running.

The system became unstable: Word could not complete “Save As”, several applications would not open, and macOS eventually required a forced power-off. No kernel panic was recorded.

I am not claiming that Codex alone caused this. The largest group of Python processes belonged to Terminal, and the specific Global BB figure run completed successfully after reboot. However, Codex was still able to continue local visualization work while the machine was already under extreme memory pressure.

It would be helpful if Codex could check system memory pressure before starting expensive local tasks such as high-resolution plotting, QGIS/GeoPandas processing, PDF/DOCX rendering, or multiprocessing. When the machine is already critically pressured, Codex should warn the user, pause, and avoid adding more concurrent work.

Please also ensure that child processes are reaped after a task finishes. The user’s applications should never be closed or killed automatically.