Windows desktop app exits unexpectedly after memory-leak and hang events

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

• #34890

Powered by Codex Action

Additional reproduction on OpenAI.Codex 26.721.11231.0 (Windows). In one newly launched app instance, I observed two DWM “ChatGPT (Not Responding)” ghost-window events. The first was followed by an AppX container teardown/relaunch; the second self-recovered after about 0.5 seconds without a relaunch.

During the fresh-instance window, combined private memory increased from about 1.56 GB to 2.82 GB in roughly nine minutes (main process about 1.09 GB; largest renderer about 849 MB; GPU process about 411 MB). Focus telemetry recorded no third-party foreground window between the ghost event and ChatGPT regaining focus. No matching Application Error, Windows Error Reporting, DWM, or NVIDIA display-driver event was present.

No session content, raw logs, local paths, account details, or credentials are included. Please investigate renderer/UI responsiveness and memory growth in the Windows desktop app.

Related current-build reproduction: renderer growth/recycling may precede the full-exit failure

I reproduced a related but not identical failure on the current Windows package:

• OpenAI.Codex 26.727.6591.0
• Internal release 26.727.51351
• Windows 11 Pro 10.0.26200
• Ample free system memory during the incident

A clean launch produced a largest ChatGPT.exe process of approximately 1.52 GB private bytes / 1.13 GB working set within about 10 seconds. In another launch, the largest PID changed after reaching approximately 1.17 GB private bytes, consistent with renderer/process recycling.

Clearing only rebuildable Chromium/GPU caches reduced the next cold-launch peak to approximately 618 MB private bytes, followed by a decline into the 233-337 MB range during short sampling. This does not establish the root cause, but it is a measurable A/B difference.

Unlike the primary report here, I did not capture RADAR_PRE_LEAK_64, AppHangTransient, or a confirmed full ChatGPT.exe AppX-container exit. Windows did record a nearby dwm.exe/dwmcore.dll crash and LiveKernelEvent 141, which I treat as correlation only.

The full measured reproduction and startup-log findings are documented in #36561:
https://github.com/openai/codex/issues/36561#issuecomment-5182680153

This data point may represent an earlier renderer-pressure/recovery stage of the broader hang/exit progression described here, but source-level confirmation is needed.

Update: reproduced on Windows app 26.730.8199.0 with multi-agent process accumulation

The issue is still reproducible after updating the Microsoft Store app to OpenAI.Codex 26.730.8199.0 on Windows 11 (10.0.26200). The new evidence points to two related failure modes: child-process retention after agent work and an Electron conversation-event storm.

Process snapshot

After several hours of multi-agent use, the Codex Desktop process tree contained:

• 14 renderer processes using about 3.35 GB RSS in total
• 22 resident plugin_mcp Node processes using about 1.05 GB
• 25 resident node_repl processes using about 0.73 GB
• main codex.exe app-server at about 1.63 GB RSS, 269 threads
• primary renderer at about 1.72 GB RSS
• roughly 8.3 GB RSS across the process tree during the diagnostic snapshot (about 0.5 GB was attributable to transient diagnostic shells/tools)
• 1,387 threads and 24,761 handles in the tree during the snapshot

The node_repl and plugin_mcp processes are created in matching pairs at the same timestamps. Many remain after their subagent reports task_complete. This looks related to the child-process cleanup problem described in #12491, now observed with the current Windows Desktop architecture.

Conversation event storm

In the current Desktop log, over roughly four hours:

• 6,043 × Received ... for unknown conversation
• 1,985 × Conversation state not found
• 261 canceled/restarted Git status or diff operations in the secondary log

That is more than 8,000 state-routing errors in one app session. The main renderer and app-server consume CPU continuously while these events are processed, and the UI becomes progressively slower when switching chats or waiting for a response to render.

Thread lifecycle correlation

A read-only audit found 426 active subagent records totaling about 6.0 GB of rollout data. 338 were already completed but remained active; five more completed during the cleanup. One parent chat alone had created 126 subagents, 115 of them completed but still active.

Archiving completed subagents reduced the active set substantially, but the already spawned MCP/REPL processes remain resident until the app is restarted. No active process was forcibly terminated during this test.

Not caused by resource exhaustion or connectivity

At the time of inspection:

• pagefile was system-managed
• about 6.4 GB physical RAM remained available
• commit usage was about 50%
• disk active time was about 7% with queue length 0
• HTTPS reachability to ChatGPT/OpenAI completed in about 0.43–0.51 s

Windows Error Reporting also recorded MoAppHang and RADAR_PRE_LEAK_64 events in the preceding app build.

Expected behavior

1. When a subagent reaches task_complete, its per-thread REPL/MCP subtree should be disposed or moved into an explicitly reusable bounded pool.
2. Completed/archived agent threads should unsubscribe from renderer events.
3. Events for unknown conversations should be dropped or reconciled without generating thousands of renderer errors.
4. Concurrency may remain configurable per session, but completed-agent retention should not grow without bound across multiple parent chats.

Raw logs and rollout files are intentionally not attached because they can contain private paths and conversation content. Sanitized excerpts or WER report IDs can be provided privately if requested.

Reproduced on Windows app 26.803.5235.0 with Remote stall and confirmed MoAppHang

Another occurrence on 2026-08-09 (Europe/Brussels):

• Codex/ChatGPT Windows package: OpenAI.Codex 26.803.5235.0
• Windows 10 x64, build 19045
• Windows recorded Application Hang Event ID 1002 for ChatGPT.exe version 151.0.7922.76 at 14:12:22.
• WER classified it as MoAppHang and stated that the program stopped interacting with Windows and was closed.
• The app launched a new process tree at 14:12:32, about ten seconds later.
• There was no Windows sleep/resume, network disconnect, AppX update, or custom watchdog action around the incident. The custom watchdog was disabled and no watchdog process was running.

In the final 63 seconds before termination, the desktop log recorded:

• 59 × Received ... for unknown conversation
• 11 × Conversation state not found
• 28 × ResizeObserver loop completed with undelivered notifications
• 1 × unexpected Codex CLI exit
• 1 × app-server connection closure

Immediately before the closure, an RMCP worker also reported a fatal transport failure for one unavailable configured local Streamable HTTP MCP endpoint. This is correlation only, but a failing optional MCP connection should remain isolated and should not terminate the desktop app-server.

The user-visible symptom was a stalled mobile Remote session. Unlike the earlier background-only activation stall, this occurrence ended in a confirmed full desktop application hang and Windows-forced closure.

Expected behavior: unknown/stale conversation events and optional MCP transport failures should be bounded or dropped. They should not build into a renderer event storm, block Remote, or end in MoAppHang and a full app restart.

No raw logs, thread IDs, local paths, endpoint names, account data, or credentials are included.

[Windows] Desktop app browser process grows to 7鈥? GB while idle and repeatedly crashes

Summary

The Codex Windows desktop app continuously allocates memory while idle. Its Electron/Chromium browser process and primary renderer grow to roughly 7鈥? GB combined, then the browser process crashes. The app may restart and reproduce the same behavior within minutes.

This is reproducible after Windows Repair and Reset, and while no task is running.

Environment

• Codex app: 26.820.9563.0 (OpenAI.Codex, x64, Microsoft Store package)
• Package status: Ok
• OS: Windows 11 Home, version 10.0.26200, build 26200, 64-bit
• Physical RAM: 31.5 GB
• GPUs:
• Intel Graphics, driver 32.0.101.8331
• NVIDIA GeForce RTX 5070 Ti Laptop GPU, driver 32.0.16.1088
• Locale/time zone: zh-CN / Asia/Shanghai

Steps to reproduce

1. Launch the Codex Windows desktop app.
2. Leave the app open without starting a task or interacting with it.
3. Observe the ChatGPT.exe processes belonging to the OpenAI.Codex package.
4. Memory rises rapidly, periodically drops after apparent garbage collection, then rises again.
5. Within a few minutes, Crashpad records a browser-process crash and the app exits or restarts.

Expected behavior

The idle app should maintain a reasonably stable memory footprint and should not crash.

Actual behavior

After a clean restart, all Codex desktop processes initially used about 1.58 GB private memory:

• Browser/main process: 531 MB
• Largest renderer: 420 MB
• GPU process: 241 MB

During a 45-second sample, with process count unchanged at 10:

| Elapsed | Total private memory | Browser/main | Primary renderer |
|---:|---:|---:|---:|
| 0 s | 3,783 MB | 2,045 MB | 1,090 MB |
| 15 s | 4,939 MB | 3,179 MB | 1,156 MB |
| 30 s | 5,555 MB | 3,518 MB | 1,290 MB |
| 40 s | 7,380 MB | 4,982 MB | 1,703 MB |
| 45 s | 5,002 MB | 2,816 MB | 1,486 MB |

Net change over 45 seconds:

• Total private memory: +1,219 MB
• Browser/main process: +772 MB
• Primary renderer: +396 MB
• Process count: unchanged
• Handle count: effectively unchanged

An earlier 30-second sample showed the same allocation/collection cycle, including the main process dropping from about 5.55 GB to 3.75 GB and immediately climbing again.

Crash records

Crashpad produced four reports during the investigation. Every sidecar identified the crashing process as the browser process:

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

| Local time (Asia/Shanghai) | Crash report ID |
|---|---|
| 2026-08-27 15:37:02 | 05cf9eae-c67a-46a3-88f9-d3e5b7174077 |
| 2026-08-27 15:42:23 | 50b5287a-6db1-4768-b37d-2a15ee4a7356 |
| 2026-08-27 15:46:55 | 5e713212-ed45-42c2-863f-33a3640acb7a |
| 2026-08-27 15:58:31 | 5d63ca63-3e2e-4779-b07d-e443075a181b |

Troubleshooting already attempted

• Windows app Repair
• Windows app Reset
• Full app restart
• Reproduction while idle with no task running
• Temporarily isolated the shared .codex/visualizations directory (8,059 files, 650.2 MB), then restarted and retested
• The leak still reproduced, peaking at 7.38 GB
• The directory was restored unchanged after the negative test

Additional observations

• The GPU process remained around 0.22鈥?.24 GB and was not the source of the growth.
• Thread and handle counts stayed approximately stable, so this does not appear to be runaway process/thread/handle creation.
• ChatGPT Classic was also installed and running, but its complete process tree remained around 0.69 GB. The abnormal processes were from the OpenAI.Codex_26.820.9563.0_x64 package.
• The main growth occurs in the Electron/Chromium browser process, with a secondary large increase in the primary renderer.

Privacy

This report is intentionally sanitized. It contains no account name, local username, prompts, session contents, configuration values, tokens, or credentials.

Confirmed a closely related UI-stuck reproduction on the newer Windows desktop package OpenAI.Codex 26.820.9563.0.

Environment:

• Windows 11 Pro x64, version/build 10.0.22000
• Desktop AppX: 26.820.9563.0 (Microsoft Store), package status Ok
• Bundled/relocated app-server CLI: codex-cli 0.150.0-alpha.8
• CODEX_CLI_PATH unset

Observed state after the update:

• The visible ChatGPT/Codex main window exists and Windows reports it as Responding=True, but the desktop UI can remain stuck.
• The app-server child process remains alive.
• A 5-second CPU sample did not show a busy loop: the busiest child used about 0.641 CPU seconds over 5 seconds, and the main process used about 0.109 CPU seconds.
• One renderer process had a working set of approximately 643 MB.
• No matching Windows Error Reporting AppHang, application-error, or crash report was present for this occurrence.

Sanitized desktop log signals:

error [electron-message-handler] ResizeObserver loop completed with undelivered notifications
error [electron-message-handler] Received turn/started for unknown conversation
error [electron-message-handler] Received turn/completed for unknown conversation

The unknown-conversation turn/started and turn/completed events occurred about three seconds apart, while the UI remained stuck. The same log also recorded network/telemetry refresh calls taking approximately 111,481 ms and 32,559 ms, although later refreshes could succeed.

This occurrence looks like renderer/conversation-state reconciliation failure rather than a CPU saturation or complete main-process hang: backend events arrive and complete, but the renderer does not associate them with a known conversation. Raw logs, account IDs, conversation IDs, session IDs, URLs, local usernames, and paths are intentionally omitted for privacy.