[Windows][26.915.4065.0] Renderer memory leak grows to 4–7 GB and repeatedly crashes; rollback to 26.903.9818.0 appears stable #46690

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

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   on Sep 19, 2026
2. github-actions commented on Sep 19, 2026

   

   github-actionsbot

   on Sep 19, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • ChatGPT macOS 26.915.31945: Codex renderer repeatedly white-screens; Renderer reaches ~120% CPU #46641

   Powered by Codex Action
3. techrote commented on Sep 24, 2026

   

   techrote

   on Sep 24, 2026 – with ChatGPT Codex Connector

   Last edited by techrote

   More actions

   Additional reproduction on a newer Windows build: OpenAI.Codex 26.917.9434.0.

   Environment:

   • Windows x64
   • Package: OpenAI.Codex
   • App version: 26.917.9434.0

   Observed behavior:

   • After a normal launch, the Codex/ChatGPT process group climbed into the multi-GB range.
   • On the first reproduction it reached roughly 4.5 GB and the renderer crashed.
   • I then fully restarted Windows to rule out stale/leaked process state.
   • After the clean OS restart, the app initially looked normal, but memory began climbing again and reached roughly 6 GB, with severe UI lag.
   • Five Crashpad sidecar files from the crashes all contain the same signature:

   {"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}

   This is a very close match to the renderer-memory-growth/crash pattern reported here, and suggests the regression is still present in 26.917.9434.0, not only 26.915.4065.0.

   The clean Windows reboot did not resolve it, so this does not look like a one-off stale renderer/process state problem. I have avoided deleting the broader Codex profile/IndexedDB/local state because the evidence points to the renderer/runtime rather than persistent user data.

   Practical impact: the desktop app is currently unreliable for unattended/overnight Codex work because the renderer can grow to several GB, become severely laggy, and crash.

   If useful, I can provide the Crashpad artifacts/process screenshots or do a controlled reproduction with additional diagnostics.

   Usage compensation request: these repeated failed/crashes, lag and troubleshooting are a major inconvenience. Could OpenAI please give usage resets as compensation for this hassle?
4. alphamediail commented on Sep 25, 2026

   

   alphamediail

   on Sep 25, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional triage signal: this now appears to be a cross-machine, multi-build Windows Desktop regression, not a one-off local state issue.

   Evidence now collected across separate reports/users:

   • This issue: Windows x64 on 26.915.4065.0, renderer grows to ~4–7 GB and repeatedly crashes with Crashpad ptype=renderer.
   • Windows 26.915.4065.0: renderer memory grows to ~3 GB, UI turns white while agent keeps running #47110: independent Windows reproduction on 26.915.4065.0 where the desktop UI fails/whitescreens while the backend remains alive; another commenter reproduced similar UI failure on the same build.
   • A new independent reproduction added above on 26.917.9434.0 shows the same multi-GB memory growth and the same Crashpad renderer signature, including after a full Windows reboot.

   The original reporter also has a useful A/B result: an in-place rollback to 26.903.9818.0 on the same machine/profile/data reduced Codex memory to ~1–2 GB and stopped the rapid renderer crash loop during normal work.

   Could a maintainer please confirm whether this has been triaged / linked to an internal bug, and whether there is a known fixed build or diagnostic you want from affected Windows users? We can provide Crashpad artifacts or additional process diagnostics privately if needed.

   Given that the issue now reproduces across multiple machines and newer builds, it would be helpful to know whether users should remain on older builds as a temporary workaround.
5. downloaderfan commented on Oct 9, 2026

   

   downloaderfan

   on Oct 9, 2026

   Last edited by downloaderfan

   More actions

   Hello,

   I too am seeing huge memory usage merely on the launch of ChatGPT desktop on Windows. Currently on 26.1002.52244.

   

   I have both ChatGPT and Claude desktop, both being idle at the time of screenshot. You can see ChatGPT takes 3x the RAM of Claude.

   When I check the individual processes, they all just say codex in Windows task manager.

   

   Here is ChatGPT task manager:

   

   Not sure what these Randerers are but they shouldn't be taking so much RAM merely on launch.
6. vitalyrue commented on Oct 13, 2026

   

   vitalyrue

   on Oct 13, 2026

   More actions

   New diagnostic evidence on Windows app 26.1007.2314.0: repeated renderer failure confirmed as V8 JavaScript heap out of memory.

   On 2026-10-13, a full native memory dump was captured at the original first-chance exception. A replacement renderer subsequently failed through the same native path. The main desktop process remained alive.

   Confirmed from the dump and process samples

   • Exception E0000008 on CrRendererMain.
   • V8 fatal path: CALL_AND_RETRY_LAST, with OOMDetails.is_heap_oom=true and no additional detail string.
   • Latest failure observed at 12:20:54 UTC. That renderer had run for approximately 11 minutes.
   • Private process memory stayed mostly 0.5 to 0.8 GiB for several minutes, then reached a sampled peak of 4.783 GiB within approximately three minutes. Samples were taken about ten seconds apart; the dump's process counters recorded a higher peak of 5.043 GiB.
   • At dump time, Windows still reported 7.232 GiB available physical memory and 6.583 GiB system commit headroom.

   Private process memory is not a separate measurement of the JavaScript heap. The native fatal path establishes the heap OOM; the process samples show the surrounding memory growth.

   History loading during the sharp memory rise

   Between 12:17:00 and 12:20:54 UTC, main-window app logs contain 562 unique response_routed requests for thread/turns/list and thread/items/list, deduplicated by requestId:

   Requests	Scope
   552	Two long local chats
   10	Another chat
   562	Total

   These are turn/item API calls, not 552 complete history pages. Separate renderer performance spans show frequent older-history loads during the same interval.

   The installed local-thread bundle has a history-gap loader with an 800 px proximity threshold. Ordinary local chats can load history without requiring a user scroll, and the loader can reevaluate gaps after applying a page. This provides a possible automatic loading path.

   Limits of the analysis

   We have not captured all page cursors, payload sizes, or JavaScript heap object retainers. The timing makes history loading a strong suspect, but does not prove a memory leak, duplicate pages, or the exact objects responsible for exhaustion.

   The older report #33285 describes a July client that resumed with five turns and then automatically drained the remaining history. It was closed as completed. I cannot confirm that this October build uses that same unconditional call; its viewport-based history loader is the current candidate for investigation.

   The public repository provides the paginated server APIs, but not the desktop renderer/build. PR #48151 adds server item anchors; PR #46721 bounds Rust TUI transcript rendering. Neither changes the desktop renderer. No client fix has been implemented or verified here.

   Suggested investigation and candidate fix

   Please compare the same long thread with automatic older-history loading enabled and disabled, recording loaded turn/item counts, page sizes, JavaScript heap size and object retainers. Check that memory settles after opening or switching chats.

   Candidate changes are a bounded initial history tail, a limit on automatic page loads without deliberate user navigation, cancellation of inactive-chat loads, and release of unused in-memory chat data while preserving saved history. These are proposals to test, not confirmed missing safeguards.

   Could a maintainer link this evidence to the current desktop memory/history bug and confirm a fixed build or the preferred renderer heap-snapshot diagnostic?

   The memory dumps and raw chat logs remain local. This comment contains aggregate measurements and code observations only.
7. jinyan550 commented on Oct 15, 2026

   

   jinyan550

   on Oct 15, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows renderer OOM evidence collected on 2026-10-15. The desktop window remains open, but its chat page whitescreens/reloads while the original task backend stays alive.

   Versions

   • Windows x64, package OpenAI.Codex.
   • App updater reports version 26.1007.71326, build 20398, production channel.
   • Installed Windows package version: 26.1007.9446.0. These are separate version fields.
   • Bundled backend: codex-cli 0.162.0-alpha.17.2.
   • The built-in update check returned up_to_date: no eligible update was offered on this machine's configured production channel.

   Captured failure

   Read-only process observation captured renderer PID 3484 naturally exiting at 2026-10-15 09:04:49.160 UTC with exit code 0xE0000008 (signed -536870904), Chromium's OOM exception code.

   Its private process memory rose from approximately 3941 MiB at 09:04:24 UTC, to 4585 MiB at 09:04:35, to 5134 MiB at 09:04:45, shortly before exit. The last sample also showed a working set of 4726 MiB. These are process-memory measurements, not measurements of the JavaScript heap.

   Multiple Crashpad sidecars identify the failing process as:

   {"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}

   The original desktop main process and original task backend both remained alive, with unchanged PIDs/start times from approximately 01:16 UTC through the latest preservation check at 09:26 UTC.

   A nearby system-memory sample, not a simultaneous measurement at the crash, showed 7731 MiB available physical memory and 41.37 GiB committed / 81.12 GiB commit limit.

   Additional observations and limits

   • Local app logs recorded approximately 5819 thread access denied failures across 11 thread IDs, primarily from thread_hydration. Thread IDs and raw logs are omitted. This is an investigation lead, not proof of the allocation source.
   • The inspected recent local chats use paginated history. Large on-disk session files alone do not establish that their full contents are resident in memory.
   • No JavaScript heap snapshot or native crash stack was captured in this investigation. The OOM exit is confirmed, but the exact allocation site, retained objects, and whether this is a leak or a large transient allocation remain unknown.
   • This production build reports allowDevtools=false, allowInspectElement=false, and allowDebugMenu=false; no remote-debugging flag or exposed listening endpoint was found.
   • The bundled codex doctor --json command is recognized, but an attempt in the normal user environment produced no report within 45 seconds. Only that newly launched diagnostic subprocess was stopped.

   Request for maintainers

   Could you please link this evidence to the relevant desktop bug and provide:

   1. A confirmed fixed Windows app build and the update channel through which it is available, or a supported mitigation.
   2. The preferred supported renderer diagnostic method, such as allocation sampling, a heap snapshot, or crash diagnostics, including expected pause/memory overhead and whether it can be enabled without restarting the app or interrupting already-running tasks.

   Running tasks must be preserved. No application restart, cache reset, installed-bundle patch, or live code injection was performed. Raw chat transcripts, local paths, account/thread identifiers, and memory dumps are not attached; this comment contains aggregate diagnostic evidence only.
8. maguirio commented on Oct 15, 2026

   

   maguirio

   on Oct 15, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows evidence on app 26.1007.71326 / build 20398 — native renderer crash with concurrent denied metadata retries

   Observed October 15, 2026 on Windows 11 Business x64, OS build 26200, approximately 32 GB installed RAM (31.46 GiB usable). Existing profile; this is not a clean-install or deterministic click-sequence reproduction.

   Versions: app 26.1007.71326, build 20398, production; MSIX package 26.1007.9446.0; app-server executable 0.162.0-alpha.17.2. The built-in updater reported up_to_date on this installation. Package and app versions are separate fields.

   Native crash and memory observations

   All times below are UTC on October 15:

   Time	Observation
   22:35:49	One desktop GUI process: 3343.1 MiB private memory
   22:37:54	Same process: 4638.5 MiB private memory
   22:39:58	Same process: 4699.4 MiB private memory
   22:40:10	New Crashpad sidecar: {"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}
   22:40:11	New renderer processes appear
   22:40:12.449	Main-window log: React root render requested again
   22:41:58	The previously large GUI process is absent from the next retained process snapshot

   The original desktop main process and GPU process remain alive with unchanged start times. Thus, checking only the main PID would miss this UI crash/reload.

   Private process memory is not a measurement of the JavaScript heap. The historical GUI process's Chromium role and exact crashing PID were not captured. The surviving sidecar has no native stack or exception code, so OOM is not confirmed on this installation. It resembles other observations here, including the same-build report in #46690 (comment), without establishing a common allocation source.

   Physical memory was 79.40% used at 22:39:50 and 74.92% at 22:40:23; these bracket the crash and are not synchronized measurements at its exact instant. Windows did not reboot. The System event log had no warnings/errors in the bounded 22:35–22:42 UTC window.

   A custom memory guard and read-only Git scan protection are present and disclosed as local interventions. The memory guard recorded no close action at this incident. Its backend-workload native memory cap is 29.885 GiB; its retained peak was 17.963 GiB when audited. No guard setting was changed and no app restart, stress test, cache purge, bundle patch or ownership/access-policy change was performed for this investigation.

   Separate, reproducible background hydration problem

   In the bounded 22:34:00–22:40:11 UTC log window:

   • 474 distinct thread/read response request IDs.
   • 460 distinct denied requests: 23 targets × 20 attempts each.
   • Denials: -32003 / thread access denied, source=thread_hydration, priority=background.
   • All 460 denied responses came from one main-window renderer in this window.
   • Maximum logged queue wait: 1 ms; median duration: 99 ms; maximum duration: 174 ms. This does not demonstrate queue saturation.
   • The same denied-read pattern continues after renderer recovery.
   • A supported read_thread call resolved one affected target to the durable host and successfully read its completed history. This does not prove that every denied target is readable or establish which wire authorization context differs.

   This matches the separately tracked background retry symptom in #51572 and the Orbit catalog investigation in #53677. Read-only inspection of this Windows build confirms that the cloud catalog merges retained references, calls hydratePinnedThreads(..., {throwOnReadError:true}), wraps errors using an existing numeric status, and uses a generic retry predicate plus one-minute error refetch. A status-less error is retryable; JSON-RPC access denial is not mapped to a terminal HTTP-style status in that wrapper. This is a concrete investigation lead, not complete attribution of every request.

   There were only 10 thread/turns/list responses across three targets, and no thread/items/list responses, in this same pre-crash window. This capture therefore does not establish the hundreds-of-history-page loading pattern described in another report. The retry loop's contribution to GUI memory growth or the native crash has not been isolated.

   Requested engineering response

   Please link this evidence to the relevant desktop issue and provide:

   1. A confirmed fixed Windows build/update channel, or a supported mitigation preserving ongoing tasks, original chats and projects.
   2. A supported way to stop repetitive denied background hydration without bypassing authorization or deleting history.
   3. The preferred native exit/stack or renderer allocation diagnostic, with its pause/memory cost and whether it requires an app restart.
   4. Confirmation whether renderer memory exhaustion and the denied catalog retry path are separate defects.

   The reloads prevent reliable supervision of ongoing work. No raw logs, conversation contents, account/thread/request/process IDs, personal filesystem paths, credentials or dumps are attached. Prepared by Codex with the account owner's authorization.