Repeatable macOS OOM: Codex/ChatGPT reaches 40–59 GB with runaway subprocess activity

Open 💬 4 comments Opened Jul 29, 2026 by jamiojala

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

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.721.81911

What subscription do you have?

ChatGPT Pro

What platform is your computer?

jamiojala@Jamis-Mac-mini ~ % uname -mprs Darwin 27.0.0 arm64 arm

What issue are you seeing?

Summary

The Codex/ChatGPT macOS app caused two genuine system out-of-memory incidents on 29 July 2026 while I was doing normal long-running Codex development work.

My Mac has 16 GB of physical RAM.

During the first incident, macOS showed ChatGPT using 40.92 GB. During the second incident, it showed ChatGPT using 59.18 GB. Both incidents triggered the macOS “Your system has run out of application memory” dialog and interrupted active work.

Incident 1

Diagnostics captured:

ChatGPT parenting 296 Node subprocesses
Approximately 9.96 GB of concurrent RSS across those Node processes
276 processes with the same eight-thread shape
Largest individual Node process: approximately 890 MB
Genuine macOS low-swap/Jetsam events

This appeared to be runaway subprocess accumulation rather than one conventional single-process memory leak.

Incident 2

The exact 296-process state was not captured again, but diagnostics recorded:

19 out-of-application-memory records
49 no-paging-space records
Sustained low-swap churn from approximately 18:57:49 to 19:07:01
2,467 process instances terminated by macOS during that period; these were not concurrent
At 18:41, the ChatGPT resource coalition contained 65 processes using approximately 4.60 GB
That coalition included 28 Node and 6 node_repl processes
Codex app-server generated approximately 8.59 GB of SQLite/file-backed writes over 36 minutes

Safari was also using approximately 5.65 GB in one snapshot, but that does not explain ChatGPT being reported at 59.18 GB or the repeated Codex-related subprocess/resource activity.

Expected behaviour

Long-running or parallel Codex work should not cause the desktop app to accumulate hundreds of subprocesses, exhaust swap, trigger system-wide memory pressure, or reach tens of gigabytes of reported memory.

Completed or abandoned child processes should be cleaned up, and the app should enforce safe resource limits.

Actual behaviour

The app repeatedly caused genuine out-of-memory conditions, froze or paused other applications, and interrupted ongoing coding work.

After relaunching, process counts and memory usage were temporarily stable, so the issue appears workload-triggered and episodic rather than a continuously growing leak immediately after startup.

Reproduction context

macOS desktop Codex/ChatGPT app
16 GB Mac
Long-running Codex development sessions
Multiple active or historical Codex tasks
No intentional manual launch of hundreds of Node processes

The issue has now occurred twice in the same day.

Diagnostics available

I have:

Screenshots showing 40.92 GB and 59.18 GB
Two full diagnostic reports
A concise incident comparison report
Process trees
Memory snapshots
Sanitized log findings
Complete diagnostic ZIP packets

The diagnostics were collected read-only:

No processes were killed during collection
No sessions, repositories, caches, logs, or configurations were modified
No sudo was used

I can provide the complete sanitized diagnostic packets privately to OpenAI engineers.

Please let me know the safest way to provide the ZIP files and affected session information.

codex-macos-oom-incident-comparison.md

What steps can reproduce the bug?

This is not yet a fully deterministic reproduction, but it occurred twice during normal long-running Codex work on the same day.

Steps observed:

Launch the Codex/ChatGPT macOS desktop app on a Mac with 16 GB of physical RAM.
Open several existing Codex tasks, including long-running sessions with substantial conversation history.
Run Codex development work involving repository inspection, shell commands, tests, and Node-based development tooling.
Leave the app running while Codex tasks continue or are resumed over an extended period.
Memory and subprocess activity increase until macOS displays “Your system has run out of application memory.”
In the first incident, ChatGPT was shown using 40.92 GB. In the second incident, it was shown using 59.18 GB.

Diagnostics from the first incident captured ChatGPT parenting 296 Node subprocesses, consuming approximately 9.96 GB of concurrent RSS. Of those, 276 had the same eight-thread process shape.

During the second incident, the exact 296-process state was not captured, but macOS recorded 19 out-of-application-memory events, 49 no-paging-space events, and sustained process churn. An earlier snapshot showed the ChatGPT coalition containing 65 processes, including 28 Node and 6 node_repl processes.

There is no standalone code snippet that reproduces this because the failure appears to occur in Codex desktop process orchestration, subprocess cleanup, session rehydration, or app-server resource management rather than in application code inside one repository.

Session ID: [paste affected Codex session ID here if available]

Token-limit usage: Not available to me.

Context-window usage: Not shown in the desktop app at the time of the incidents. The affected sessions were long-running and contained substantial history, but I cannot provide an exact context percentage.

What is the expected behavior?

Codex should safely manage and clean up child processes created during development work.

Long-running sessions, resumed tasks, Node-based repositories, or parallel Codex work should not cause hundreds of persistent subprocesses to accumulate, exhaust system RAM and swap, or trigger a system-wide out-of-memory condition.

Completed, disconnected, or abandoned subprocesses should be terminated or reused appropriately. The app should also enforce reasonable process and memory limits, release session-related resources when no longer needed, and remain responsive without interrupting active coding work or forcing other applications to pause.

Additional information

The issue occurred twice on 29 July 2026 on the same 16 GB Mac.

Incident 1:

ChatGPT displayed at 40.92 GB
296 Node subprocesses under ChatGPT
Approximately 9.96 GB concurrent RSS across those subprocesses
276 processes shared the same eight-thread shape
Largest individual Node process was approximately 890 MB
Genuine macOS low-swap events were recorded

Incident 2:

ChatGPT displayed at 59.18 GB
19 out-of-application-memory records
49 no-paging-space records
Sustained low-swap churn from approximately 18:57:49 to 19:07:01 local time
2,467 process instances were terminated by macOS during the period; these were not all concurrent
At 18:41, the ChatGPT coalition contained 65 processes using approximately 4.60 GB
The coalition included 28 Node and 6 node_repl processes
Codex app-server generated approximately 8.59 GB of SQLite/file-backed writes over 36 minutes

Safari was also using approximately 5.65 GB in one snapshot and contributed to overall memory pressure. However, that does not explain ChatGPT being reported at 40.92 GB and 59.18 GB or the repeated Codex-related subprocess activity.

After restarting the app, memory usage temporarily returned to normal and showed periodic release rather than immediate continuous growth. This suggests the issue is workload-triggered and episodic.

I have two screenshots, full read-only diagnostic reports, process trees, memory snapshots, sanitized log findings, and complete diagnostic packets. I can provide the full ZIP files privately to OpenAI engineers. I have not uploaded the raw packets publicly because they may contain local paths or other sensitive metadata.

No processes were killed during diagnostic collection, no sessions or repositories were modified, no caches or logs were deleted, and no sudo access was used.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 29 days ago

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

#35269
#35582

Powered by Codex Action

jamiojala · 29 days ago

Additional process-ownership findings after relaunch

After the two OOM incidents, I restarted ChatGPT/Codex and intentionally continued only one Codex thread. I did not reopen, resume, or reactivate the three tasks that had been running before the crash because I was trying to avoid triggering the issue again.

Despite that, process inspection showed that the relaunched Codex app-server had restored or retained complete MCP/helper bundles for four Codex tasks:

1 task that I actively resumed
3 idle tasks that I did not reactivate after the crash

Each task had its own bundle containing plugin MCP servers, node_repl, and XcodeBuildMCP.

Across the four task bundles, the live footprint was:

28 per-session MCP/helper OS processes
29 processes when including the shared Computer Use service
Approximately 54.4 MiB total RSS

The three idle tasks alone retained:

18 logical helpers
21 OS processes

There was no evidence of an active respawn loop during this inspection. The PIDs remained stable across repeated samples and had been alive for approximately 21–46 minutes.

This means the retained helper groups are real, but their current memory footprint is far too small to explain the earlier 40.92 GB and 59.18 GB OOM incidents. My normal MCP configuration therefore does not appear to be the primary cause.

The important finding is that Codex automatically rehydrated or retained task-level runtime infrastructure for inactive threads after relaunch, even though I had resumed only one thread.

Other material processes during the inspection were:

Existing Next.js preview server: approximately 948 MiB RSS
Largest renderer: approximately 530 MiB RSS
Codex app-server: approximately 250 MiB RSS
Codex Chronicle: approximately 164 MiB RSS

System memory was approximately 77% free at the time, so the machine was not currently in the runaway state.

This supports the conclusion that the catastrophic memory condition is episodic. Normal steady-state MCP/helper usage does not account for the 40–59 GB failures, but automatic restoration or retention of inactive task runtimes may be relevant if heavier task-specific processes or resources are also retained under certain conditions.

No processes were killed, restarted, disabled, or modified during this inspection, and Git remained clean.

ToadPresident · 28 days ago

Additional reproduction: exact app version, ~700 related processes, ~30 GiB aggregate RSS, swap nearly exhausted

I am seeing the same failure on another Apple Silicon Mac using the exact app version from this issue. This snapshot was collected while the affected Codex tasks were still running; I have not restarted the app yet because doing so would interrupt active work.

Environment

ChatGPT/Codex: 26.721.81911 (build 5973)
Bundled Codex CLI: 0.146.0-alpha.3.1
macOS: 26.4.1 (25E253), arm64
Physical memory: 48 GiB
App uptime at capture: approximately 1 day 5 hours
Snapshot time: 2026-07-31 04:39 +08

User-visible incident

macOS displayed ChatGPT at approximately 95–96 GB and showed “Your system has run out of application memory.”

Read-only live process snapshot

106 processes whose command belongs to the ChatGPT app bundle: approximately 6.38 GiB aggregate RSS
300 npm exec wrapper processes: approximately 11.65 GiB aggregate RSS
At least 301 Node/MCP tool processes: approximately 11.92 GiB aggregate RSS
Coarse total across those three non-overlapping command categories: approximately 29.95 GiB aggregate RSS
Main ChatGPT process itself: only approximately 389 MiB RSS
System swap: approximately 51.9 / 53.0 GiB used, with approximately 1.1 GiB free

The RSS sum is a process-level diagnostic and can double-count shared pages. Swap is system-wide and cannot be attributed byte-for-byte to ChatGPT. However, the combination of hundreds of Codex-owned helper processes, roughly 30 GiB of current aggregate RSS, and nearly exhausted swap closely matches the 95–96 GB application-memory warning.

Approximate command-family matches from the same live snapshot were:

Lark MCP stack: 188 process records, approximately 7.76 GiB RSS
Firebase stack: 100 records, approximately 4.05 GiB RSS
Context7 stack: 102 records, approximately 3.99 GiB RSS
Filesystem MCP stack: 106 records, approximately 3.89 GiB RSS
Exa stack: 102 records, approximately 3.78 GiB RSS
node_repl: 51 records, approximately 0.49 GiB RSS

These family figures include wrapper/child layers and should not be added again to the aggregate totals above. The pattern strongly suggests repeated per-thread/per-runtime MCP stacks that are not being reclaimed, rather than a single renderer heap growing to 95 GB.

Current-main source hypothesis

Two lifecycle gaps still appear present on current main:

In AsyncManagedClient::shutdown(), shutdown cancels startup but the StartupOutcomeError::Cancelled branch performs no explicit process termination.
In LocalProcessTerminator, Unix termination sends SIGTERM and schedules a delayed SIGKILL on a detached thread, but does not await process exit or deterministically reap the process group.

This does not yet prove those paths are the sole cause. A deterministic process-level regression test is still needed, especially around startup cancellation, thread/runtime teardown, and npm/Node descendant cleanup.

I am aware that #19753 and #29608 fixed related session-shutdown and superseded-manager paths. The exact-version reproduction here suggests that a cancellation/reconnect/plugin-runtime path remains uncovered or has regressed. This also appears related to #30408 and #26984.

No processes were killed, no configuration or project data was modified, and no raw logs or local paths are included here. I can provide a sanitized before/after process tree and help build a focused start–cancel–shutdown regression test. If maintainers agree with this direction and explicitly invite an external contribution, I would be willing to prepare a narrowly scoped fix.

YangHeenfb · 3 days ago

Two same-day macOS memorystatus SIGKILLs at ~41 GB on a newer Codex Desktop build

I encountered the same user-visible failure class (“ChatGPT stopped unexpectedly”) twice on August 24, 2026 PDT, using a newer ChatGPT/Codex Desktop build.

Environment

ChatGPT/Codex Desktop: 26.818.61809 (build 7019)
Bundled Codex CLI: 0.149.0-alpha.4.3
macOS: 26.3 (25D125), arm64
Physical memory: 16 GiB

Direct OS evidence

First incident:

At 17:39:37.983 PDT, the macOS kernel reported that the system was unhealthy with swap_low: 1.
At 17:39:38.054 PDT, it recorded:

memorystatus: killing largest compressed process codex [4562] 41243 MB

The desktop then recorded the same app-server process exiting with SIGKILL, classifiedAsExpected=false, followed by a fatal-error broadcast.

Second incident, about 90 minutes later:

At 19:09:42.785 PDT, the kernel recorded:

memorystatus: triggering no paging space action

It then recorded:

memorystatus: killing largest compressed process codex [11432] 40962 MB

At 19:09:43.484 PDT, the desktop recorded app_server_connection.closed with SIGKILL, classifiedAsExpected=false, followed by fatal_error_broadcasted.

Neither incident coincided with an explicit app-server restart request. Explicit restart events occurred only afterward.

Workload immediately before the second kill

The interrupted turn lasted approximately 8 minutes 53 seconds and contained:

24 tool calls
24 recorded model-request/token-count events
30 reasoning response items
Input growing from 110,040 tokens on the first request to 190,274 tokens on the final request, of which 189,184 were cached
Approximately 3.735 million cumulative input tokens processed across the requests in that turn

A read-only sample approximately 28 minutes 45 seconds before the second kill showed the app-server at about 409 MiB RSS.

The 409 MiB RSS sample and the kernel’s 40,962 MB memorystatus figure are different memory metrics, so I am not treating them as a precise growth curve. They do, however, show that the catastrophic condition developed within a relatively short window.

Interpretation boundary

I did not establish that these incidents involved the same hundreds-of-Node/MCP-process accumulation reported in some other reproductions. I also cannot identify which internal allocation or resource was retained.

The evidence establishes this sequence:

A long-history, high-context, tool-heavy workload was active.
The local codex app-server reached a kernel-reported figure of approximately 41 GB.
macOS entered low-swap/no-paging-space memory pressure.
macOS terminated the app-server with SIGKILL.
Codex Desktop displayed “ChatGPT stopped unexpectedly.”

This evidence does not, by itself, prove a particular internal memory leak, allocator issue, history-projection bug, SQLite issue, or child-process lifecycle defect.

Expected behavior

The app-server should enforce a bounded memory policy, compact or release retained state, or fail the current turn gracefully before exhausting system paging space. A single high-context tool turn should not cause the local app-server to reach tens of gigabytes and be killed by macOS.

I intentionally omitted raw logs, session JSONL, task IDs, absolute paths, project content, and other private metadata. I can provide additional sanitized evidence through a private OpenAI channel if requested.