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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   performance

   on Jul 16, 2026
2. github-actions commented on Jul 16, 2026

   

   github-actionsbot

   on Jul 16, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [app][macOS] Browser-use Node workers accumulate to 10–18 GB, exhaust swap, and suspend unrelated apps #33319
   • Codex Desktop reaches 130 GB memory during Ultra multi-agent swarm (24 GB Mac) #33390
   • [macOS App] Opening integration-heavy tasks spawns persistent renderers that survive archive and idle #33469

   Powered by Codex Action
3. zakblacki commented on Jul 18, 2026

   

   zakblacki

   on Jul 18, 2026

   More actions

   I can confirm the same bug happening after upgrading
4. bbingz commented on Jul 24, 2026

   

   bbingz

   on Jul 24, 2026

   More actions

   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: [app][macOS][26.707.91948] ChatGPT/Codex repeatedly grows to 55 GB and freezes the system #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.
5. bbingz commented on Jul 24, 2026

   

   bbingz

   on Jul 24, 2026

   More actions

   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 Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #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 logs_2.sqlite-wal grows without bound into tens of GB #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 [app][macOS][26.707.91948] ChatGPT/Codex repeatedly grows to 55 GB and freezes the system #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.
6. truzozenith commented on Jul 31, 2026

   

   truzozenith

   on Jul 31, 2026 – with ChatGPT Codex Connector

   More actions

   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.
7. ajayshah76 commented on Sep 16, 2026

   

   ajayshah76

   on Sep 16, 2026

   Last edited by ajayshah76

   More actions

   Additional user report with current app details and sanitized pre-reboot evidence.

   Symptoms reported by the user

   • On September 16, 2026, the Codex desktop app became very slow. Typing a few characters into the message composer then froze the interface and input stopped.
   • Repeated quit/reopen attempts did not reliably restore normal behavior. The user reports normal behavior after reboot.
   • On other occasions, leaving Codex untouched for a while reportedly led to memory use of about 100 GB, a system-wide stall, and force quit. The 100 GB value and recurrence are user-reported; no independent measurement of that peak was recovered.

   Environment and recovery context

   • Currently installed Codex desktop app: 26.908.70816, build 9275.
   • Apple Silicon Mac with 48 GiB physical RAM.
   • The pre-reboot memory reports identify macOS 26.4.1 (25E253).
   • The system is now running macOS 27.0 (26A428). Software update history records the macOS 27 installation at 08:01:44 PDT on September 16; the current boot time is 08:14:53 PDT.
   • Recovery therefore coincided with both a reboot and an OS upgrade. Their effects cannot be separated from this evidence. The installed app version is verified now; the exact app version at each earlier symptom was not separately established.

   Verified pre-reboot diagnostic summary

   • Memory-pressure reports from 01:15 through 04:58 PDT include the same main Codex process IDs.
   • At 04:57 and 04:58, the sum of resident-page counts for processes named Codex/codex/ChatGPT was about 13.77 GiB and 13.61 GiB, respectively. These are name-based snapshot totals, not a complete process-tree or continuous memory trace.
   • At 04:58, the largest named Codex process was about 8.67 GiB resident, a renderer about 1.69 GiB, and a service about 1.11 GiB. Values use the report's 16,384-byte page size.
   • At 04:07, free pages fell to 2,596, approximately 40.6 MiB. The reports also record other processes being terminated for compressor-space shortage.
   • No named Codex process was marked as terminated in these inspected memory snapshots. No Codex crash report was found in the checked diagnostic folders.

   These snapshots establish system memory pressure with Codex among the consumers. They do not prove that Codex caused all of the pressure, identify a memory leak, verify a 100 GB footprint, or directly capture the later typing freeze. The exact trigger and relation between the two reported symptoms remain unknown.

   Expected behavior

   Memory use should stabilize and resources should be reclaimed. The composer should remain responsive without a system-wide stall, force quit, or reboot.

   This is additional evidence for a similar symptom on macOS; it is not a confirmed duplicate root cause. No raw logs, prompts, session transcripts, private paths, customer data, or secrets are attached.
8. ppravdin commented on Sep 25, 2026

   

   ppravdin

   on Sep 25, 2026

   More actions

   +1 — can confirm this on Apple Silicon running macOS 26.5.2 (25F84) with 16 GB RAM after updating the app.

   In our case, the runaway memory growth did not stop at pausing applications — it triggered a complete kernel panic and hardware watchdog reset:

   Environment

   • Platform: Apple Silicon (Mac16,10), 16 GB RAM
   • OS: macOS 26.5.2 (Build 25F84)
   • App: ChatGPT / Codex macOS Desktop App (freshly updated)

   Panic Log & Diagnostic Summary

   • Panic signature:

     panic(cpu 0 caller 0xfffffe00502d4ef4): userspace watchdog timeout: no successful checkins from configd (1 induced crashes) in 185 seconds
     service: configd (1 induced crashes), total successful checkins: 27375, last successful checkin: 185 seconds ago
     Kernel Extensions in backtrace: com.apple.driver.AppleARMWatchdogTimer
     Boot faults: wdog,reset_in_1
     

   • Attributed Memory:
     • ChatGPT process footprint: 48.69 GB resident / ~51.05 GB (residentMemoryBytes: 51055525480).
     • Memory compressor status at panic: Compressor Info: 52% of compressed pages limit (OK) and 100% of segments limit (BAD) with 43 swapfiles and OK swap space.
     • Available free memory dropped to ~14 MB (906 pages).

   Observed Failure Chain

   1. Runaway memory retention pushed the system into severe compressor and swap thrashing (43 active swap files).
   2. The extreme paging load deadlocked macOS configd and blocked over 40 dependent system processes attempting mach_msg send to com.apple.SystemConfiguration.configd.
   3. After configd failed userspace check-in for 185 seconds, macOS watchdogd triggered AppleARMWatchdogTimer, forcing a hardware reset (wdog,reset_in_1).
9. ajayshah76 commented on Sep 26, 2026

   

   ajayshah76

   on Sep 26, 2026

   More actions

   Follow-up: recurrence on 26.917.71314 with a verified 15.1G renderer footprint

   Following my September 16 report in this issue, the slowdown recurred on September 25, 2026. This time there is direct evidence for one renderer retaining a large footprint after a same-day restart.

   Environment

   • Codex desktop app 26.917.71314, build 10954, bundle com.openai.codex.
   • Codex Framework 153.0.8010.53.
   • Apple Silicon Mac, 48 GiB physical RAM.
   • macOS 27.0, build 26A428.

   Sequence and attempted mitigation

   1. In the morning, Codex was slow during typing, scrolling, and responses. Multiple groups of optional local MCP servers were running.
   2. Disabled the Context7, Perplexity, Playwright, and Bear MCP server configurations, then fully quit and reopened Codex at approximately 07:18 PDT. The app process tree fell from 142 to 27 processes, and responsiveness immediately improved. This does not isolate the effect of disabling servers from the effect of restarting.
   3. At approximately 21:22 PDT, the computer was slowing down again. The user reported no intentional active Codex work. Idle status over the entire interval was not instrumented or independently verified.
   4. The same renderer launched at 07:18:28 PDT was still running after approximately 14 hours. Activity Monitor showed 15.13 GB for that renderer. All four MCP configurations remained disabled.

   Verified measurements at recurrence

   Renderer PID 38090, parent app PID 37414:

   vmmap -summary 38090
   Physical footprint:         15.1G
   Physical footprint (peak):  15.2G
   Writable regions: Total=16.5G written=15.1G(91%) resident=752.4M(4%) swapped_out=14.4G(87%) unallocated=1.4G(8%)
   

   • footprint -p 38090 --swapped --noCategories independently reported a 15 GB footprint, rounded by that tool.
   • A three-second sample also reported physical footprint 15.1G and peak 15.2G.
   • At the first process snapshot, renderer CPU was 0.0%, while ps RSS was only 826304 KiB. RSS alone substantially understated the footprint.
   • sysctl vm.swapusage reported total 19456.00M, used 18414.00M, free 1042.00M. These are system-wide swap figures, not attribution of all swap to this renderer.
   • The vmmap swapped_out figure is quoted as reported; it is not a separate measurement of this process's disk swap allocation.

   What this establishes, and remaining limits

   The restart provided immediate relief, but the optional MCP-server mitigation did not prevent substantial renderer memory retention later the same day. This narrows the unresolved symptom to a renderer, rather than only accumulated MCP server processes.

   The exact renderer page/window, retained objects, allocation source, and code-level leak mechanism are not yet identified. vmmap warned that it could not examine the PartitionAlloc malloc zone, so detailed allocation interpretation is incomplete. There is no continuous footprint trace or reliable minimal reproducer yet.

   The user has also seen approximately 90–100 GB on other occasions. Those peaks remain user-reported; the independently captured renderer footprint in this update is 15.1G. This is related symptom evidence, not proof that every report in this issue has the same root cause.

   Expected behavior

   Renderer memory should stabilize or be reclaimed during idle periods. Normal desktop use should not require repeated application restarts to recover memory and responsiveness.

   This update contains only sanitized measurements. No raw logs, heap dumps, prompts, conversation contents, screenshots, private file paths, customer data, or credentials are attached.
10. nullsec444 commented on Sep 26, 2026

    

    nullsec444

    on Sep 26, 2026 – with ChatGPT Codex Connector

    More actions

    Follow-up on a newer build (2026-09-27)

    Environment:

    • Codex macOS app: 26.924.22138 (build 11645)
    • macOS: 26.6.2 (25G83), Apple Silicon, 24 GiB RAM

    The reporter says Codex-related memory use reached about 30 GB earlier in the day, followed later by sustained high CPU. The exact memory counter and a process-footprint sample were not captured, so the 30 GB figure is user-reported rather than independently verified.

    A sanitized Activity Monitor snapshot during the CPU episode showed Google Chrome for Testing at 100.2% CPU, Codex Renderer at 21.5%, and Codex Service at 8.7%. The screenshot does not show process parent/child relationships, so it cannot establish whether that Chrome process was launched by Codex or attribute its full CPU use to Codex. No raw logs, prompts, or session contents are attached.

    This is a recurrence on a newer app build than the reports above. The exact trigger and whether the memory and CPU symptoms share a root cause are not yet isolated. Please investigate this against the existing macOS resource-growth reports.