[Windows][26.721.4979.0] Renderer repeatedly soft-restarts after rapid memory growth in long-running sessions

Open 💬 4 comments Opened Aug 2, 2026 by goosehovel

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

Feedback ID

019fb674-caa5-7453-bd03-6a47839c6137

What version of the Codex App are you using?

26.721.4979.0

Bundled Chromium / ChatGPT.exe version observed: 150.0.7871.128

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows x64

What issue are you seeing?

The Codex desktop app repeatedly performs what appears to be a soft restart during long-running project-agent workloads.

The main ChatGPT.exe process and Codex backend remain alive, but the active Chromium renderer disappears and is replaced by a new renderer process. The window briefly behaves as though the application restarted, without a complete application relaunch.

During a live audit:

Renderer PID 5068 disappeared.
Renderer PID 68328 replaced it.
The replacement renderer grew from approximately 381 MB to 1.96 GB in 30 seconds.
It reached approximately 2.9 GB within two minutes.
The Codex backend fluctuated between approximately 7.3 GB and 8.5 GB.
Windows separately recorded RADAR_PRE_LEAK_64 against ChatGPT.exe on July 29, 2026.

This occurred without clipboard access.

The machine was not under general resource pressure:

Approximately 117 GB of physical RAM remained available.
Total committed memory was approximately 43%.
Disk latency was negligible.
Windows recorded no system-wide resource-exhaustion event.
Both installed Store packages reported healthy signatures and package status.

The application had been running for approximately 19 hours.

Workload context

This is a persistent, production-style workflow using multiple long-running project agents and tasks.

The local Codex session collection is approximately 15.7 GB. Several individual session transcripts are approximately 300–550 MB, and multiple large transcripts were actively updating during the audit.

Large pastes and long-running tasks appear to aggravate the failure. The likely trigger is excessive renderer/application-state growth while loading, rendering, updating, or synchronizing large task histories.

Moving all work into new empty tasks is not a viable workaround because the workflow depends on persistent agents retaining long-running project context.

What steps can reproduce the bug?

The failure is recurrent but the exact minimal trigger has not yet been isolated:

Launch Codex Desktop on Windows.
Keep the application running for many hours.
Maintain multiple persistent, long-running project tasks with large histories.
Continue updating several large tasks and occasionally paste or process large bodies of text.
Monitor the Chromium renderer processes and the Codex backend.
Observe rapid renderer working-set growth.
The active renderer eventually disappears and is replaced while the main application/backend remain alive.
The Codex window briefly behaves as though it restarted.

What is the expected behavior?

Renderer memory should remain bounded during long-running sessions.
Large persistent task histories should not cause repeated renderer replacement.
The UI should remain stable while active agents continue running.
Session loading and updates should be paginated, virtualized, streamed, or unloaded sufficiently to avoid materializing excessive state.
Archived or completed task state should not remain unnecessarily resident until a full application restart.

Actual behavior

The renderer grows by multiple gigabytes within minutes, disappears, and is replaced. The main process and Codex backend survive, producing a visible soft restart rather than a complete application relaunch.

Working diagnosis

The evidence is consistent with a renderer/state-scaling memory defect aggravated by large persistent session history:

editor content, rendered transcript elements, task state, and backend message/state representations may be duplicated;
one or more large transcripts may be repeatedly materialized or rerendered;
session updates may cause unbounded DOM, cache, serialization, or IPC allocations;
the renderer appears to cross a recovery threshold and is then recycled.

This is an inference from the measured process behavior. Source-level confirmation is needed from the maintainers.

Related issues

#35963 — Windows memory-leak/hang events with RADAR_PRE_LEAK_64
#36291 — RADAR_PRE_LEAK_64, AppHang, and surviving/headless ChatGPT.exe processes
#26362 — renderer replacement while the main app/app-server remain alive
#18589 — renderer RAM runaway followed by an apparent app refresh/restart
#20867 — long-thread rendering degradation on Windows

This report differs by documenting the bridge between those symptoms: measured explosive renderer growth immediately followed by confirmed renderer PID replacement, while the backend remains alive and the system still has abundant free memory.

Additional information

I submitted the affected session through the in-app feedback mechanism using the Feedback ID above.

I can provide redacted Event Viewer records, process-memory captures, timestamps, transcript-size measurements, and post-update reproduction results if maintainers request them.

No application settings, processes, session files, or system configuration were changed during the audit. Raw transcripts and project contents are not attached publicly because they may contain sensitive information.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 26 days ago

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

#35963

Powered by Codex Action

goosehovel · 26 days ago

Updated-build reproduction: issue persists in 26.727.6591.0

The Codex desktop update did not fix this renderer soft-restart/recycle failure.

Updated environment

Codex package: 26.727.6591.0
Internal release: codex@26.727.51351
Chromium runtime: 150.0.7871.182
Store update installed successfully
Package status reports healthy

Before/after comparison

| Measurement | Earlier build | Updated build |
|---|---:|---:|
| Codex package | 26.721.4979.0 | 26.727.6591.0 |
| Chromium runtime | 150.0.7871.128 | 150.0.7871.182 |
| Renderer replacement | Confirmed | Confirmed again |
| Replacement growth | 381 MB → 1.96 GB in 30 sec | 185 MB → 1.85 GB in 58 sec |
| Later renderer size | ~2.9 GB | 3.5 GB after ~4.2 minutes |
| Backend memory | 7.3–8.5 GB after long uptime | 4.2–6.9 GB within 11 minutes |

The updated renderer initially grew somewhat slower, but the workload differed, so I cannot attribute that difference to the update. It still reached the same dangerous memory range and recycled.

Live process timeline

Main PID 99956 remained alive throughout.
Renderer PID 69452, already using approximately 3.57 GB, disappeared.
Replacement renderer PID 78536 appeared.
Replacement renderer reached:
1.19 GB in 29 seconds
1.85 GB in 58 seconds
3.50 GB after approximately four minutes
The Codex backend fluctuated sharply and peaked around 6.94 GB.

This was again a Chromium renderer recycle/recovery, not a complete application restart.

System-pressure checks

This still was not caused by full-system RAM exhaustion:

Approximately 109 GB physical memory available
Approximately 98 GB committed against a 204 GB limit
No Resource Exhaustion Detector events
No new Codex WER crash or hang record
No Crashpad dump
Current Sentry error queue was empty

The lack of WER, Crashpad, or Sentry records appears consistent with the application silently handling the renderer failure internally.

Active workload during reproduction

The overall Codex session archive had decreased from approximately 15.7 GB to 8.56 GB, but the active workload remained very large:

11 session files updated during the audit
Combined active footprint: approximately 2.74 GB
Largest active transcripts: approximately 883 MB and 592 MB
Several additional active transcripts between approximately 230 MB and 313 MB
The audit task itself was only approximately 1.8 MB

This suggests the pressure is associated with maintaining and processing several enormous active tasks concurrently, rather than the current foreground conversation alone.

Updated conclusion

Product failure mode: still present
Primary trigger: several huge active tasks plus rapid task/render-state processing
Full PC or Windows memory problem: no evidence
Corrupt installation: no evidence
Another reinstall: unlikely to help

No processes, application data, tasks, settings, caches, or clipboard contents were changed or accessed during this updated-build audit.

goosehovel · 25 days ago

Severity escalation: renderer loop now progresses to full application exits

The failure has escalated beyond renderer-only soft restarts. Codex is now also exiting completely during the same large-history/recovery workload.

Important workflow clarification

Archiving is technically available, but it is not an acceptable workaround for this workflow. These tasks contain required, long-running project context used by persistent agents. Archiving or abandoning them would destroy the continuity the project depends on.

The application needs to handle large persistent histories safely; the valid workload should not be treated as disposable.

Concrete trigger now isolated

The strongest trigger is Codex repeatedly reloading enormous task histories while long-running agents continue streaming updates.

Observed active histories:

Active task 019fb674-caa5…: approximately 671 MB and still growing
Task 019fac87-2035…: approximately 995 MB

Observed history polling:

thread/turns/list requested 110 times for the 671 MB task in eight minutes — about once every 4.4 seconds
thread/turns/list requested 76 times for the 995 MB task — about once every 6 seconds
Approximately 291 history responses across six large tasks during startup/recovery

The live log shows repeated thread/turns/list responses for both giant histories only seconds apart, continuously, rather than a bounded initial load.

Renderer and application failure timeline

Main renderer reached approximately 4 GB
Renderer disappeared at approximately 8:12:57 AM local time
A new React-root render was requested at approximately 8:12:58 AM
Replacement renderer reached 4.09 GB within ten minutes
Backend memory was another approximately 3.56 GB
Windows still had approximately 107 GB physical memory available

Windows also recorded two genuine full Codex AppX-container exits:

8:06:40 AM local time
8:08:55 AM local time

There was no accompanying WER crash, Crashpad dump, Sentry error, Resource Exhaustion Detector event, or captured exception/exit code. The renderer recovery is therefore occurring silently, and the later full exits are not producing useful native crash telemetry.

Duplicate UI delivery

Live agent events are being delivered to both:

the primary renderer window
the avatar/pet overlay renderer

The log shows the same reasoning-summary events emitted to rendererWebContentsId=1 (primary) and rendererWebContentsId=2 (avatarOverlay). This duplicates UI work during already extreme history loading and streaming pressure.

Agent workload is valid; UI handling is defective

No evidence ties the failure to a specific shell command, tool call, or agent action. The running agent is an accelerator because it streams into a 671 MB history, but it is not directly crashing Windows or the backend.

In plain terms: the workload is valid; Codex's repeated full-history loading and renderer-state handling are defective.

SSH retry loop is secondary, not causal for the measured renderer recycle

A stale remote SSH entry produced approximately 840 timeout/reconnect attempts overnight and should be cleaned up separately. However, during the measured renderer failure, the renderer disappeared before the associated SSH timeout completed. Therefore the dead SSH host did not trigger that specific renderer restart.

Requested investigation

Please investigate:

Why thread/turns/list repeatedly reloads giant histories every few seconds
Whether full task history payloads are being resent, reparsed, retained, or rerendered on each refresh
Whether active-history polling can use deltas, cursors, pagination, or incremental updates
Whether giant inactive histories can remain logically active without being fully materialized in the renderer
Whether primary-window and avatar-overlay delivery duplicates state, serialization, or React rendering work
Why renderer recovery can escalate to full AppX-container exits without WER, Crashpad, or Sentry telemetry
How users can preserve persistent agent context without archiving or abandoning large tasks

The detailed live log is available through the previously submitted Feedback ID. No settings, tasks, processes, SSH configuration, caches, or files were changed during the audit.

logohere · 23 days ago

Additional Windows 26.727.6591.0 reproduction: cold-launch spike and cache A/B

I independently reproduced the same ChatGPT.exe renderer/main-process memory behavior on the current Windows package.

Environment

Windows 11 Pro: 10.0.26200
Microsoft Store package: OpenAI.Codex 26.727.6591.0
Internal desktop release from logs/config: 26.727.51351
GPU: NVIDIA GeForce RTX 4070 SUPER
System memory was not under pressure (approximately 25 GB available during inspection)

Reproduction and measurements

Fully terminated all ChatGPT.exe processes.
Launched Codex Desktop into a local workspace.
Within approximately 10 seconds, the largest ChatGPT.exe process reached:

1,524.7 MB private bytes
1,133.1 MB working set
1,779 handles / 62 threads

In an earlier launch, the largest process reached 1,171.7 MB private bytes before the largest PID changed as processes were recycled.
The app had 8-9 concurrent ChatGPT.exe processes.

Controlled cache A/B

With the app fully stopped, I removed only rebuildable Chromium/Electron cache directories (Cache, Code Cache, GPUCache, ShaderCache, GrShaderCache, GPUPersistentCache, Dawn caches, and component/extension CRX caches). Login storage, conversation databases, and project data were left intact.

After relaunch:

Largest process at approximately 10 seconds: 617.5 MB private / 662.8 MB working set.
Subsequent samples over approximately 32 seconds fell to 337.2 MB, 335.2 MB, and 233.1 MB private rather than continuing to grow.

This is not proof that cache state is the root cause, but it materially changed the cold-launch footprint and stopped the short-window growth in this reproduction.

Additional startup log churn

The desktop logs also repeatedly reported:

Git root/origin resolution failures for two restored worktrees because Git rejected their ownership (dubious ownership).
Repeated filesystem-watch failure: Invalid request: AbsolutePathBuf deserialized without a base path.

Adding only those two worktrees to Git's exact safe.directory list removed the ownership error from the next sampled startup log. This suggests failed restored-workspace metadata/watch work may amplify startup pressure, although it does not by itself explain the renderer allocation.

Co-occurring Windows events

Windows recorded a dwm.exe / dwmcore.dll crash and LiveKernelEvent 141 graphics-watchdog reports near the incident window. I am reporting these as correlation only; causality is not established.

Requested investigation

In addition to long-history polling, please check cold-start restoration paths for:

Whether Chromium/Electron disk caches are being materialized or retained excessively.
Whether failed Git metadata and filesystem-watch initialization retries retain renderer/main-process state.
Whether renderer recovery releases allocations across all web contents, including the hidden overlay renderer.
Whether the app can bound startup memory and expose a supported cache-reset/diagnostics action.

No project contents, raw transcripts, credentials, or private log payloads are included here.