Windows Codex causes system-wide memory growth through unaccounted shared/GPU memory

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

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.3748.0

What subscription do you have?

api

What platform is your computer?

Windows 11 64-bit on a Lenovo Legion R7000P APH8 (82Y9)

What issue are you seeing?

Summary

On Windows, leaving the Codex desktop app open for about one hour causes system memory usage to continuously increase, even when the app is idle. Eventually, Windows becomes unresponsive and Task Manager may also freeze.

The abnormal memory growth is not reflected in the private memory of the Codex processes.

Environment

  • OS: Windows 11 64-bit
  • Codex desktop version: 26.707.3748.0
  • Device: Lenovo Legion R7000P APH8
  • Physical memory: 16 GB
  • CPU/GPU:
  • AMD Radeon 780M integrated graphics
  • NVIDIA GeForce RTX 4060 Laptop GPU
  • Codex architecture: Electron desktop app with GPU acceleration
  • MCP configuration: empty ([mcp_servers] contains no servers)

Reproduction

  1. Start Codex on Windows.
  2. Leave Codex open for approximately one hour.
  3. Do not run any task or tool.
  4. Monitor Windows memory usage and system commit charge.
  5. The issue reproduces even when Codex is idle.

Observed behavior

Before the system became unresponsive:

  • Physical memory usage reached approximately 95% to 99%.
  • Available physical memory dropped to approximately 100 MB.
  • Windows Explorer, Task Manager, mouse movement, and desktop switching became extremely slow or unresponsive.
  • CPU, disk, and network utilization were not saturated.

The following values were captured by a 10-second system monitor:

| Metric | Initial | Before failure |
|---|---:|---:|
| System committed memory | 12.84 GB | 21.19 GB |
| Available physical memory | ~5.4 GB | ~0.1 GB |
| Total private memory of all processes | ~5.80 GB | ~5.81 GB |
| Nonpaged pool | 848 MB | 1.46 GB |
| Paged pool | 579 MB | 814 MB |

The most important observation is that system commit increased by approximately 8.34 GB, while total process private memory increased by only approximately 10.6 MB.

At the same time:

  • ChatGPT.exe remained around 0.9 GB.
  • codex.exe remained around 25 MB.
  • No normal user-mode process accounted for the missing committed memory.

Additional evidence

The machine uses a hybrid AMD/NVIDIA graphics configuration. The AMD Radeon 780M driver was originally:

  • Version: 31.0.14005.22001
  • Date: 2023-11-08

After updating the AMD driver to:

  • Version: 32.0.31021.5001
  • AMD Adrenalin: 26.6.4 WHQL

and rebooting, physical memory usage became stable during subsequent testing.

This suggests that Codex's Electron GPU/DirectX rendering path may be triggering a shared-memory, graphics-memory, or driver-level allocation leak. However, I cannot identify the exact driver pool tag yet.

Mitigation

Updating the AMD Radeon 780M driver and rebooting significantly improved the issue. I also tested with plugins disabled and Codex cache reset, but those changes alone did not resolve the problem.

Expected behavior

Codex should not continuously increase system commit charge while idle. GPU/shared memory and kernel allocations should be released when renderer surfaces are no longer in use.

Request

Could the Codex team investigate:

  • GPU process memory and shared memory allocations over time
  • DirectX/DXGI resource lifetime in the Windows Electron renderer
  • Interaction with hybrid AMD/NVIDIA graphics systems
  • Whether renderer or GPU-process resources are released correctly while Codex is idle
  • Whether a built-in memory diagnostic or automatic renderer restart could be added when memory growth is detected

I can provide the monitoring CSV files and additional diagnostic data after removing personal paths and account information.

What steps can reproduce the bug?

Reproduction

  1. Start Codex on Windows.
  2. Leave Codex open for approximately one hour.
  3. Do not run any task or tool.
  4. Monitor Windows memory usage and system commit charge.
  5. The issue reproduces even when Codex is idle.

What is the expected behavior?

<img width="1584" height="1028" alt="Image" src="https://github.com/user-attachments/assets/55314064-aaa4-4123-b97c-c687a5d82eb3" />

<img width="1578" height="1012" alt="Image" src="https://github.com/user-attachments/assets/a0f918c0-ab56-4e5f-b89c-930691928ad1" />

Additional information

_No response_

View original on GitHub ↗

3 Comments

TangAnNing · 1 month ago

Hope these tips can help you guys

github-actions[bot] contributor · 1 month ago

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

  • #31743

Powered by Codex Action

NicolayBang · 23 days ago

I may be seeing this desktop resource issue overlapping with a separate oversized-session problem tracked in #22991.

On Windows, the Codex desktop app can trigger a system-wide stall rather than only an unresponsive application window:

  • Mouse input can freeze or become severely delayed.
  • Task Manager does not always show an obvious CPU or per-process memory spike when it happens.
  • Several Codex/ChatGPT processes and child processes are visible during the problem. Some may be expected for the desktop architecture, but they appear duplicated or excessive when the stalls occur.
  • The GUI application's resource use appears to grow over time, suggesting possible retained memory or unreleased child processes.
  • I have not observed the same ongoing resource-growth and system-wide-freeze pattern during normal Codex CLI use.

An unusually large thread can trigger the behavior in my case, but I do not think that fully explains the GUI-specific system impact. The thread-loading failure is documented separately in #22991; I am commenting here because the mouse freeze, weak correlation with Task Manager's per-process figures, and apparent GUI-only resource retention align with this issue.

I am not attaching raw session data because it contains private conversation and tool output.