›_ Codex Issues
Codex Issues / #38059

[Windows Desktop][26.803.10989.0] Memory grows to 8.8 GB while idle and UI freezes after 1-2 messages

Open 💬 3 comments Opened Aug 11, 2026 by Dororo367
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • Codex Desktop Microsoft Store package: OpenAI.Codex 26.803.10989.0 (x64)
  • Also reproduced on the previous installed version: 26.803.8161.0
  • OS: Windows 11 Home x64, version 10.0.26200, build 26200
  • CPU: AMD Ryzen 7 7735HS
  • RAM: 32 GB (31.2 GB usable)
  • GPUs: AMD Radeon Graphics (32.0.11038.3) and NVIDIA GeForce RTX 4060 Laptop GPU (32.0.16.1047)
  • Parsec Virtual Display Adapter is installed (0.45.0.0)

Summary

Codex Desktop's ChatGPT.exe child processes progressively consume memory even when no Codex task is running. The app then becomes unresponsive, commonly after only one or two messages, and must be fully restarted. Restarting temporarily lowers memory usage, but the behavior returns.

This persists after reducing the local profile to only 9 active threads and zero open subagent edges, so it does not appear to require thousands of active threads or one unusually large active conversation.

Observed behavior

  • In a Task Manager screenshot taken while Codex had no active task, the ChatGPT (11) process group used 8,823.6 MB and about 22.2% CPU.
  • The three largest ChatGPT.exe child processes in that idle capture used about 4,247.0 MB, 2,500.2 MB, and 1,620.9 MB.
  • codex.exe itself was only about 25.6 MB in that capture; the large consumers were ChatGPT.exe children.
  • An earlier idle capture showed 4,682.8 MB total, including one ChatGPT.exe process at 3,114.0 MB.
  • In a fresh launch of the current build, the 12 Codex/ChatGPT processes had already reached 2,738.6 MB working set / 2,404.8 MB private memory after 4.3 minutes.
  • Windows Event Viewer recorded Application Hang event 1002 for ChatGPT.exe on 2026-08-11, stating that the program stopped interacting with Windows and was closed.
  • Windows Error Reporting also recorded RADAR_PRE_LEAK_64 for ChatGPT.exe on 2026-08-08.
  • The rest of Windows remains usable. Restarting Codex restores it only temporarily.

Steps to reproduce

  1. Launch Codex Desktop on Windows.
  2. Open a small local thread or simply leave the app open with no agent task running.
  3. Send one or two short messages, or leave the app idle for a while.
  4. Observe the ChatGPT.exe child-process memory increasing progressively in Task Manager.
  5. Try to send another message. The UI eventually stops responding; sometimes the message is not submitted at all.
  6. Fully restart Codex. Memory drops temporarily, then the same growth and freeze recur.

The exact time to failure varies, but on this machine the app currently needs restarting after roughly every second message.

Expected behavior

When no task is running, Codex Desktop memory and CPU usage should stabilize. Sending ordinary messages should not make the renderer/UI stop responding, and the app should not require repeated full restarts.

Troubleshooting already attempted

  • Updated from 26.803.8161.0 to 26.803.10989.0.
  • Fully exited and restarted Codex repeatedly.
  • Moved about 723 MB of Codex logs, Sentry queue data, and renderer/browser caches to a recoverable backup; no improvement.
  • Disabled multi_agent; no improvement.
  • Backed up the local state, closed 68 stale open subagent edges, and reduced active local threads from 73 to 9 with 0 open edges; no improvement.
  • Cold-archived the two largest rollout histories (one local rollout around 510 MB, and one remote thread tree around 1.70 GB); no improvement.
  • Verified that the machine has 32 GB RAM and an adequate Windows page file; this is not a simple out-of-memory configuration.

The cleanup result distinguishes this from reports that reproduce only with thousands of active thread metadata rows. The issue still reproduces with 9 active local threads.

Privacy and diagnostics

Raw session JSONL, SQLite databases, and application logs are not attached publicly because they can contain prompts, local paths, tool output, and private project data. Sanitized Task Manager screenshots with the per-process breakdown are available, and additional aggregate diagnostics can be provided if maintainers request them.

Possibly related

  • #24510 - unbounded active thread metadata/history processing
  • #21134 - renderer/app-server memory growth on long threads
  • #20214 - frequent Windows UI freezes/stutters
  • #34907 - Windows high CPU and UI freezes on an older build
  • #33582 - severe Desktop memory growth on macOS

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 16 days ago

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

  • #37829
  • #36920

Powered by Codex Action

Dororo367 · 16 days ago

Update: confirmed local RPC retry loop

I found a reproducible failure signature that appears to explain the CPU, RAM growth, log churn, and UI freezes.

While Codex Desktop is idle, the renderer repeatedly calls the local app-server method app/installed. The app-server rejects it with JSON-RPC -32600:

Invalid request: unknown variant app/installed

The server's advertised method list includes app/list, but not app/installed.

Measured impact

  • 35,137 failed app/installed calls were recorded in one evening of use.
  • Live sample: 41 new failures in 10.8 seconds (3.8/sec).
  • During that 10.8-second sample, the ChatGPT.exe process group accumulated 23.3 CPU-seconds and used 2.64 GB working set.
  • The calls come from both the primary renderer and a hidden avatarOverlay renderer.
  • Each failure logs a long list of supported methods, causing rapid log growth/rotation and likely amplifying the resource problem.

Reinstall/profile control

This persists after reinstalling Codex and after renaming/recreating %LOCALAPPDATA%\OpenAI\Codex.

Process command-line inspection confirms that the affected desktop app-server is the Store package's bundled binary:

...\OpenAI.Codex_26.803.10989.0_x64__...\app\resources\codex.exe ... app-server

Therefore the renamed %LOCALAPPDATA%\OpenAI\Codex directory (a separately downloaded CLI/runtime) is not the app-server producing this error.

This looks like a frontend/app-server API compatibility regression in the Desktop package, or an unbounded retry after an unsupported method response. Raw logs are intentionally not attached because they can contain private prompts and local data.

I reviewed #37829. It looks closely related (Windows 26.803, memory growth with zero conversations), but this comment adds the concrete app/installed retry signature.

Dororo367 · 16 days ago

Timeline correction

The issue was first observed before the currently installed 26.803.10989.0 build and has persisted through approximately 2-3 subsequent Desktop updates.

Please do not interpret the version in the title as the introduction point. It is the latest affected build that was measured. The app/installed retry signature therefore appears to be a persistent cross-version regression, or a feature/configuration rollout that remains enabled across updates, rather than a one-time corrupted installation.

The behavior also persisted after uninstall/reinstall and after recreating the separately downloaded local CLI/runtime directory. This further reduces the likelihood of a simple stale local installation.