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

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.

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

macOS Desktop resource retention returns after restart: app-server/renderers/helpers/log churn and system lag #35269
macOS Desktop: completed recurring automations retain CUA node_repl workers #35582

Powered by Codex Action

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.

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.

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.

Additional reproduction on current ChatGPT macOS build 26.825.32147

I am seeing what appears to be the same episodic runaway-memory failure on the current unified ChatGPT macOS app.

Environment

Device: 2023 Mac mini
Chip: Apple M2 Pro
Physical/unified memory: 16 GB
macOS: Golden Gate 27.0
ChatGPT: 26.825.32147 (released Aug 28, 2026; “Powered by Codex & OWL”)

Observed behavior

During ordinary use, ChatGPT typically sits around ~8 GB of application memory.
Every now and then, memory usage suddenly grows to 40 GB or more.
When this happens, the Mac becomes effectively frozen/unresponsive.
This is intermittent rather than a constant high-memory state.

I have not yet captured a process-tree/subprocess-count snapshot during the runaway state, so I cannot confirm whether this instance is specifically caused by the same Node/MCP subprocess accumulation described above. However, the user-visible failure mode is very similar, and importantly it is still occurring on build 26.825.32147.

No serial number or other device-identifying information is included here.

Follow-up: single `codex` process reached 45.30 GB; swap 43.17 GB on 16 GB Mac

A subsequent incident on the same machine provides stronger evidence that at least one failure mode is a single-process codex/app-server runaway, not only subprocess accumulation.

Environment (same as previous comment)

2023 Mac mini
Apple M2 Pro
16 GB unified memory
macOS Golden Gate 27.0
ChatGPT 26.825.32147 (released Aug 28, 2026)

Activity Monitor snapshot during the incident

codex: 45.30 GB (PID 22746)
Codex (Service): 934.4 MB
Codex (Renderer): 866.6 MB
https://chatgpt.com: 770.0 MB
another Codex (Renderer): 632.5 MB
ChatGPT: 428.5 MB
additional Codex renderers: ~217.5 MB, 213.8 MB, 185.0 MB
system Swap Used: 43.17 GB
Activity Monitor memory-pressure graph was at/near the critical range

Activity Monitor also displayed impossible 0 bytes values for Physical Memory / Memory Used / App Memory while the system was under this extreme pressure, presumably because monitoring/UI was itself degraded during the OOM condition.

This snapshot is important because the main ChatGPT process was only ~428 MB while a single codex process accounted for 45.30 GB. That looks closer to the single app-server growth described in #29510 than to a pure hundreds-of-subprocesses failure, although both may share a lifecycle/session-state root cause.

A screenshot of this Activity Monitor state is available; it is not attached here because it includes the local macOS username. The key metrics above are transcribed exactly.

New likely trigger identified: reopening a large website-building Work thread

I have now noticed a reproducible pattern that may explain the episodic runaway memory growth.

The steep memory increase seems to begin especially when I open a ChatGPT Work/Codex conversation that is associated with a large website ChatGPT previously created. When that thread is opened, it appears that the app starts restoring/importing a very large amount of project/thread state, including many images and other website assets. This is when the codex process begins climbing rapidly.

This observation is consistent with other reports involving large/image-heavy Codex rollout histories or thread restoration causing large app-server memory growth. It suggests the trigger may be reopening/deserializing a large Work/Codex thread or its associated persisted project state, rather than ordinary idle use.

Previous measurements from the same machine/build remain:

ChatGPT 26.825.32147
2023 Mac mini, M2 Pro, 16 GB unified memory, macOS 27.0
single codex process observed at 45.30 GB
swap observed at 43.17 GB
ChatGPT UI process itself only ~428 MB during that incident

I have not yet isolated whether the primary trigger is the conversation/rollout history itself or loading the website/project assets, but reopening that particular large website-building thread is now the clearest observed trigger.

A/B test strongly implicates the large thread history, not the website itself

I ran a simple comparison using the same website/project, but opened it from a brand-new Work/Codex chat instead of the very large original development thread that contains extensive history and many uploaded images.

Result in the new chat

codex: ~800 MB
Codex (Service): ~906 MB
largest Codex (Renderer): ~829 MB
ChatGPT: ~298 MB
visible website web-content process: ~132 MB
total App Memory: ~3.64 GB
Swap Used: 0 bytes

The site opened and was usable without runaway growth.

Comparison with the old thread

Opening the old, image-heavy website-development thread had previously driven:

a single codex process to 45.30 GB
system swap to 43.17 GB
the Mac into severe memory pressure / near-freeze

This strongly suggests that the trigger is restoring/deserializing the very large thread/session history (which contains extensive prior tool output, site-building work, and many uploaded images), rather than simply loading the website or its assets.

This is not absolute proof of the exact internal mechanism, but it is now a reproducible A/B difference: same website, fresh chat = ~0.8 GB codex and 0 swap; old large thread = 45.3 GB codex and 43.17 GB swap.

I am seeing a related macOS Codex Desktop failure during ordinary coding/use: Node processes accumulate and remain running after work completes. The count can reach 30+ lingering Node processes, at which point Codex becomes unreliable enough that I need to restart it or manually terminate the processes.

This is not limited to a single unusually large task; it has happened repeatedly through normal usage. The expected behavior is that task/tool helper processes are reaped once no longer needed, without requiring a restart or manual process cleanup.

Additional reproduction on Codex 26.901.41600: 726 MCP/CUA subprocesses, disk exhaustion, and ~18 GiB recovered after restarting the app

I observed a similar failure on September 6, 2026, with a newer macOS desktop build. This report adds a measured before/after restart comparison.

Environment

Codex desktop: 26.901.41600, build 7982; bundle identifier com.openai.codex
macOS 26.5.2 (25F84), arm64
16 GiB RAM; internal APFS container approximately 228 GiB
Local tool services included Context7, Playwright, and the built-in computer-use Node/REPL environment.
Before restart, the desktop app had been running for approximately 24 hours; some tool processes had been alive for over 17 hours.

Measurements

Metric	Before restarting Codex	After restarting Codex
Observation time (JST, UTC+09:00)	September 6, 13:14–13:18	September 6, 13:31
Descendant Node/MCP/CUA processes	726	35
Context7 npm launcher processes	90	4
Playwright npm launcher processes	90	4
CUA node_repl processes	180	8
CUA node processes	186	11
Other node processes	180	8
Combined footprint of the 726 tool processes	22.94 GiB	Not measured
VM volume allocation	~28 GiB	~10 GiB
Internal disk free space	~550 MiB	~19 GiB

The tool process count had increased from approximately 486 earlier that morning to 726. PID/PPID traversal attributed the selected processes to the Codex desktop app's process tree; they were not unrelated Node processes elsewhere on the machine.

The 726-process footprint measurement was collected around 13:17 using macOS footprint and completed with no reported errors. The minimum free-space snapshot was collected at 13:18. Process footprint is a memory-accounting measure, not physical resident RAM or exclusive swap allocation, and should not be added to VM disk usage.

Observed sequence

Use the desktop app across multiple tasks with MCP and computer-use tools available.
Over several hours, observe increasing numbers of retained tool subprocesses and growing VM disk allocation.
Internal free space falls to approximately 550 MiB.
Fully quit and reopen only Codex.
Tool process count drops to 35, VM allocation falls by approximately 18 GiB, and free space recovers to approximately 19 GiB. No macOS reboot was performed.

This is not yet a minimal deterministic reproduction. I have not established which processes remained legitimately attached to active tasks versus inactive/completed tasks, so I am reporting suspected lifecycle/resource retention rather than a proven specific memory leak.

Relevant controls

Storage was measured independently using df, diskutil apfs list, and sysctl vm.swapusage.
Simulator dyld caches and device-install delta caches were empty during the later disk-exhaustion event; the Go module cache remained absent.
Earlier cache cleanup temporarily helped. A separate periodic simulator-cache maintenance command had been disabled because invoking it could trigger a rebuild; it remained disabled during the 13:14–13:18 measurements.
The diagnostic assistant performed no additional filesystem deletion during the key Codex restart comparison.
No raw task transcripts, account identifiers, credentials, or personal file paths are included here.

Could the team investigate MCP/CUA process cleanup or reuse across task completion, task resumption, and other lifecycle transitions? The before/after app restart comparison strongly implicates accumulated desktop tool resources, although it does not identify the internal trigger.

Also use of RAM goes to 40 gb on 8gb MacBook pro m1 and gives javascript errors

@jamiojala

@jamiojala do you by any chance have the mongodb-mcp-server extension installed? Repeatedly getting this issue, so I ran investigation:

Investigation complete. The main issue is a large leak of orphaned MongoDB MCP processes from previous Codex/ChatGPT sessions.

94 stale MongoDB MCP process families
- Their original Codex parents have exited; they are now adopted by launchd (PPID 1).
- Started between 5 and 10 September.
- Consume approximately 8.4 GiB RSS.
16 current MongoDB MCP families
- Owned by the current ChatGPT/Codex app server, PID 43669.
- Consume approximately 2.3 GiB RSS.
- These are mongodb-mcp-server@1.13.0 --readOnly instances.

If so, could be related to mongodb-js/mongodb-mcp-server#1515 (comment)

@jamiojala do you by any chance have the mongodb-mcp-server extension installed? Repeatedly getting this issue, so I ran investigation:

Investigation complete. The main issue is a large leak of orphaned MongoDB MCP processes from previous Codex/ChatGPT sessions.

94 stale MongoDB MCP process families

Their original Codex parents have exited; they are now adopted by launchd (PPID 1).

Started between 5 and 10 September.

Consume approximately 8.4 GiB RSS.

16 current MongoDB MCP families

Owned by the current ChatGPT/Codex app server, PID 43669.

Consume approximately 2.3 GiB RSS.

These are mongodb-mcp-server@1.13.0 --readOnly instances.

If so, could be related to mongodb-js/mongodb-mcp-server#1515 (comment)

Thanks for the pointer. I checked my current MCP configuration, installed extensions and running processes, and found no mongodb-mcp-server entry or running instance. I can’t confirm the exact installation state during the original July incidents from today’s check, but currently there’s no evidence connecting my case to MongoDB MCP. The subprocess accumulation symptoms look similar, though the underlying cause may diffe

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Summary

Incident 1

Incident 2

Expected behaviour

Actual behaviour

Reproduction context

Diagnostics available

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 29, 2026

jamiojala commented on Jul 29, 2026

Additional process-ownership findings after relaunch

ToadPresident commented on Jul 30, 2026

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

Environment

User-visible incident

Read-only live process snapshot

Current-main source hypothesis

YangHeenfb commented on Aug 25, 2026

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

Environment

Direct OS evidence

Workload immediately before the second kill

Interpretation boundary

Expected behavior

RudolfBW commented on Aug 29, 2026

Additional reproduction on current ChatGPT macOS build 26.825.32147

Environment

Observed behavior

RudolfBW commented on Aug 30, 2026

Follow-up: single codex process reached 45.30 GB; swap 43.17 GB on 16 GB Mac

Environment (same as previous comment)

Activity Monitor snapshot during the incident

RudolfBW commented on Aug 31, 2026

New likely trigger identified: reopening a large website-building Work thread

RudolfBW commented on Aug 31, 2026

A/B test strongly implicates the large thread history, not the website itself

Result in the new chat

Comparison with the old thread

lambegraham commented on Sep 5, 2026

sylineyk commented on Sep 6, 2026

Additional reproduction on Codex 26.901.41600: 726 MCP/CUA subprocesses, disk exhaustion, and ~18 GiB recovered after restarting the app

Isaina commented on Sep 6, 2026

lambegraham commented on Sep 10, 2026

jamiojala commented on Sep 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Follow-up: single `codex` process reached 45.30 GB; swap 43.17 GB on 16 GB Mac