Codex Desktop reaches 130 GB memory during Ultra multi-agent swarm (24 GB Mac)

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

• #33319
• #33368

Powered by Codex Action

I hit what appears to be the same failure class on another 24 GB Apple Silicon Mac, with additional post-incident evidence that may help narrow the trigger.

Observed impact

• macOS 26.5, build 25F5053d
• 24 GB physical RAM
• Force Quit reported 106.92 GB for ChatGPT/Codex
• Other applications were using roughly another 15 GB
• macOS remained alive long enough to present the global “out of application memory” dialog and let me force-quit Codex. Memory compression and swap appear to have absorbed an extraordinary amount of pressure before the app finally became untenable.
• After force-quitting and restarting Codex, memory returned to normal.

Parent-thread evidence

The likely trigger was one unusually large lead thread:

• 119 context windows
• 95 task starts
• 24 context compactions
• 32 spawn_agent calls
• 2,232 code-mode execution records
• 747 regular tool calls
• 44 related rollout files totaling approximately 263 MB

The important timing evidence is that three children belonging to this parent were restored/spawned almost simultaneously shortly before the OOM:

01:41:34 UTC  /root/pr23_reconcile
01:41:41 UTC  /root/pr25_reconcile
01:41:49 UTC  /root/pr28_ops

Each child’s session metadata directly identifies the same parent thread. Each also received a guardian session. The three main child rollouts rapidly reached approximately 19.6 MB, 21.6 MB, and 19.5 MB.

These children had originally been created with fork_turns: "all", so they inherited the very large lead-thread history. This suggests a possible restore/resume amplification path: several full-history agents are hydrated concurrently, each resumes repository/tool state, and resource use is not backpressured against available system memory.

Process evidence

The macOS unified log also shows a large burst of short-lived descendants associated with the ChatGPT/Codex process tree, including repeated git, bash, and node processes. Groups of Git operations appeared repeatedly, including git add -u and git status activity.

The kernel repeatedly logged messages of this form for the spawned processes:

triggered unnest of range ... of DYLD shared region in VM map ...
While not abnormal for debuggers, this increases system memory footprint
almost permanently (until the shared region is re-slid).

This may explain why the value attributed to the ChatGPT application coalition grew far beyond physical RAM: the failure was not necessarily a single renderer heap reaching 106.92 GB, but an aggregate coalition/VM footprint amplified by extreme child-process churn, compressed memory, and swap.

There may be overlap with #29084’s unbounded desktop Git watcher, although this workspace did not yet receive the same nested-repository negative-control testing. In this incident, the strongest direct trigger is concurrent restoration of several very large fork_turns: all subagents, followed by process churn.

Suggested safeguards

• Bound concurrent restore/hydration of subagents by memory budget.
• Avoid eagerly duplicating or hydrating complete parent history for every restored child.
• Apply backpressure before restoring guardians, MCP runtimes, and repository watchers for several children at once.
• Debounce and cap concurrent Git/checkpoint subprocesses.
• Surface a recoverable warning and pause agent restoration before system-wide memory exhaustion.
• Record per-thread/per-agent RSS, child count, restore reason, and coalition footprint so future reports can identify the owning component directly.

I am happy to provide sanitized unified-log excerpts or the exact parent thread ID privately if that would help. I use Codex heavily and am reporting this because I would genuinely like to help make the multi-agent workflow more robust.