›_ Codex Issues
Codex Issues / #33582

[app][macOS][26.707.91948] ChatGPT/Codex repeatedly grows to 55 GB and freezes the system

Open 💬 5 comments Opened Jul 16, 2026 by aledonato
💡 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)?

26.707.91948 (build 5440)

What subscription do you have?

Unknown (signed-in Codex desktop user)

What platform is your computer?

Darwin 25.5.0 arm64 arm

  • macOS 26.5.2 (25F84)
  • MacBook Pro (MacBookPro18,3)
  • Apple M1 Pro
  • 16 GB RAM

What issue are you seeing?

The unified ChatGPT/Codex macOS app repeatedly grows until it exhausts application memory and freezes the whole computer.

The macOS Force Quit window reported:

  • ChatGPT: 55.31 GB
  • Claude: 5.69 GB
  • Microsoft Teams: 3.66 GB
  • Parallels Desktop: 4.30 GB
  • Chrome: 897.4 MB

ChatGPT was by far the largest consumer. macOS displayed: Your system has run out of application memory. Multiple unrelated applications were marked as paused.

This is not a one-time event. Quitting or restarting ChatGPT/Codex temporarily restores memory usage to below approximately 1 GB, but the leak returns during continued Codex use and the machine freezes again.

The app was freshly auto-updated on 2026-07-16 and the installed build matches the latest official appcast entry, so there is no newer update available.

After restarting the app following the incident, macOS still showed approximately 2.07 GB of swap in use.

What steps can reproduce the bug?

  1. Open the unified ChatGPT desktop app and use Codex for local development tasks.
  2. Keep the app running through ongoing or long tasks.
  3. Memory usage grows over time.
  4. Eventually macOS reports that application memory is exhausted and pauses unrelated apps.
  5. Force quit or restart ChatGPT/Codex.
  6. Memory returns to normal temporarily, but the same problem recurs during subsequent use.

The workload includes code-mode tasks and may include MCP/browser workers. At the time of the post-restart inspection, the normal ChatGPT/Codex process tree included renderer processes, two node_repl processes, codex-code-mode-host, and the Codex app-server. No large orphan-process accumulation was visible after restart, so the exact leaking child from the incident could not be identified retroactively.

What is the expected behavior?

ChatGPT/Codex memory should stabilize at a reasonable level and reclaim renderer, browser, MCP, and Node worker resources after tasks complete. It must not consume tens of gigabytes, exhaust swap, or suspend unrelated applications.

The app should enforce an aggregate memory budget or stop and warn before causing a system-wide memory emergency.

Additional information

This reproduces on the latest build available on 2026-07-16 and appears related to:

  • #33319
  • #19333
  • #18589
  • #12491

The new evidence here is recurrence on version 26.707.91948 / build 5440 with the ChatGPT resource coalition reaching 55.31 GB on a 16 GB Apple Silicon Mac. A screenshot of the Force Quit window is available if maintainers need it.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33319
  • #33390
  • #33469

Powered by Codex Action

zakblacki · 1 month ago

I can confirm the same bug happening after upgrading

bbingz · 1 month ago

Analysis (community)

Thanks for tracking this — attempting a residual-focused analysis aligned with docs/contributing.md (invitation-only: analysis in-thread, no unsolicited PR).

  • Issue under review: #33582 — [app][macOS][26.707.91948] ChatGPT/Codex repeatedly grows to 55 GB and freezes the system
  • Theme / radar cluster: Mac multi-GB memory / freeze long threads (desktop-oom)
  • Reporter posture: static + local evidence where available; not claiming a maintainer invite.

Observed (from issue + public residual signal)

What version of the Codex App are you using (From “About Codex” dialog)? 26.707.91948 (build 5440) ### What subscription do you have? Unknown (signed-in Codex desktop user) ### What platform is your computer? Darwin 25.5.0 arm64 arm - macOS 26.5.2 (25F84) - MacBook Pro (MacBookPro18,3) - Apple M1 Pro - 16 GB RAM ### What issue are you seeing? The unified ChatGPT/Codex macOS app repeatedly grows until it exhausts application memory and freezes the whole computer. The macOS Force Quit window r

Root-cause hypothesis

Long-thread / multi-session desktop retains process pools and multi-GB heaps; may combine MCP unreaped children + history retention + renderer growth.

High-level fix outline (not a PR)

  • Memory budget per thread; unload inactive sessions.
  • Reap helpers; bound concurrent MCP batches (Windows reports of five batches).
  • Fail-first: long-thread fixture + process/memory snapshot assertions.

Related

#33582, #32797, #12491 — cross-link rather than fork.

Questions for maintainers

  1. Is the intended long-term policy documented for this area (especially sandbox gitdir / log TRACE defaults)?
  2. Preferred residual anchor issue if several open threads describe the same mechanism?
  3. If the high-level outline above is roughly aligned, would an invited PR with failing-first tests be welcome later — or is an internal fix preferred?

Happy to refine with more measurements or code pointers. No unsolicited PR from me.

bbingz · 1 month ago

Analysis (community)

Residual analysis for #33582 (macOS ChatGPT/Codex grows to multi-tens of GB) — invitation-only. Not a pile-on of Windows WMI/taskkill mega-threads (#34260 family). Focus: macOS memory/disk growth mechanisms that OSS can measure. No unsolicited PR.

Deterministic evidence (runtime + code co-factors)

Runtime on this host (codex-cli 0.146.0-alpha.6):

  • ~/.codex/logs_2.sqlite alone is 1778548736 bytes (~1.66 GiB) with WAL 30405632 bytes still active.
  • TRACE-dominant histogram: TRACE|94907 of ≈137150 rows.
  • High-fanout targets (codex_api::sse::responses 37252, codex_app_server::outgoing_message 19558, codex_tui::markdown_stream 15085) show continuous allocation + serialization work during streams.

Code co-factors (5dd992acd3):

  • SQLite sink defaults TRACE (codex-rs/state/src/log_db.rs default_filter L55) with 2s flush batches — sustained write + page cache pressure.
  • Realtime/voice paths note large payloads (codex-rs/tui/src/app/thread_events.rs ≈L141) — relevant when Desktop keeps long-lived threads.
  • MCP helper lifecycle gaps (see residual notes on #12491) can compound RSS if children are not reaped across multi-hour sessions.

Root-cause hypothesis

macOS “tens of GB” reports are likely a sum of:

  1. Unbounded diagnostic SQLite growth under TRACE-default.
  2. Long-lived Desktop process retaining transcript/realtime buffers.
  3. Occasional unreaped helpers / caches.

Treating it only as “Activity Monitor says Codex is big” misses the measurable SQLite + streaming fanout co-factor still present on 0.146.x.

High-level fix outline (not a PR)

  1. Cap/rotate logs_2.sqlite (shared with #28997 budget work).
  2. Desktop: bound in-memory transcript/realtime buffers; page to disk with limits.
  3. Doctor command: report DB size, WAL size, child process count, RSS.
  4. Fail-first: long-run soak (N hours synthetic stream) asserts RSS + DB under caps on Darwin CI.

Questions for maintainers

  1. Preferred metrics endpoint for Desktop growth (doctor vs internal telemetry)?
  2. Is #33582 the macOS residual anchor separate from Windows process-storm issues?
  3. Would an invited PR for doctor metrics + DB caps be welcome?

No unsolicited PR from me.

truzozenith · 27 days ago

Independent corroboration on a later unified ChatGPT/Codex build, with a process-level snapshot captured immediately after macOS raised the application-memory warning.

Environment

  • ChatGPT/Codex macOS app: 26.727.40816 (build 6067)
  • Bundled Codex runtime: codex-cli 0.146.0-alpha.9.2
  • macOS: 26.5.2 (25F84)
  • MacBook Pro 16-inch (2023), Apple M2 Pro, 16 GB RAM
  • Observed: 2026-07-31 around 18:23 IST

Incident

During normal Codex desktop use with three task windows open, macOS displayed “Your system has run out of application memory.” The Force Quit Applications window attributed 24.14 GB to ChatGPT and paused the app.

A screenshot of the warning is available, but I am not attaching raw application logs or session data publicly because they may contain private project information.

Sanitized diagnostics

The long-lived Codex app-server had been running for about 5h 42m. The first process snapshot showed approximately 2.48 GB RSS for:

/Applications/ChatGPT.app/Contents/Resources/codex   -c features.code_mode_host=true app-server --analytics-default-enabled

A vmmap -summary snapshot of that process reported:

Physical footprint:          5.6G
Physical footprint (peak):  11.7G
Writable regions: Total=14.4G, resident=2.5G, swapped_out=3.1G
TOTAL: 16.1G virtual, 2.7G resident, 3.1G swapped

Allocator details:

DefaultMallocZone size:       12.2G
DefaultMallocZone allocated:   4.8G
Allocation count:          2,887,561
Fragmentation:               388.2M
MALLOC_SMALL:                  5.4G total, 2.0G resident, 2.1G swapped
MALLOC_SMALL (empty):          5.6G total

The ChatGPT process tree at follow-up contained about 38 processes with roughly 4.3 GB aggregate live RSS, including 12 renderer processes totaling about 2.0 GB. Current system swap was:

total = 9216.00M
used  = 7736.31M
free  = 1479.69M

The smaller live RSS after the warning does not account for the earlier 24.14 GB Force Quit attribution, but the app-server peak footprint, swapped allocator regions, and renderer footprint confirm severe retained memory and swap pressure within the ChatGPT/Codex runtime.

Expected

Memory should stabilize and be reclaimed as task views, renderer state, diagnostics, and helper sessions become inactive. The application should enforce an aggregate memory budget or stop/warn before causing a system-wide application-memory emergency.

Workaround

Quit and relaunch ChatGPT/Codex. This releases the retained heap temporarily.

This adds an independent recurrence on build 6067, later than the build originally reported here.