[Windows App] codex-computer-use.exe leaks ~18 MB/s until system commit is exhausted

What version of the Codex App are you using?

• Codex Desktop (Microsoft Store): 26.707.9981.0
• Bundled Computer Use runtime: @oai/sky 0.4.20

What platform is your computer?

• Windows 11 Pro, x64
• OS version: 10.0.26200
• Physical memory: approximately 32 GB
• Display setup: one 3840x2160 virtual display adapter and one 2560x1440 physical display, both configured around 144 Hz

What issue are you seeing?

A single codex-computer-use.exe process shows sustained, apparently unbounded private-memory growth until Windows is close to exhausting its commit limit.

This is not the aggregate memory of Electron renderers or multiple stale helper processes. The growth is concentrated in one Computer Use helper process.

Observed measurements from one live session:

| Observation | Working set | Private bytes |
| --- | ---: | ---: |
| Initial Task Manager screenshot | ~3.7 GB | not shown |
| First detailed sample | 4.93 GB | 11.55 GB |
| Start of 24.7-second sample | 5.88 GB | 12.60 GB |
| End of 24.7-second sample | 6.28 GB | 13.05 GB |
| Later observation | 8.84 GB | 17.33 GB |
| Latest observation before filing | 10.99 GB | 30.54 GB |

During the 24.7-second sample, private bytes increased by approximately 446 MB, or about 18.6 MB/s. CPU usage was approximately one logical core.

At the latest system sample:

• Committed memory: 86.76 GB
• Commit limit: 88.55 GB
• Available physical memory: 1.72 GB
• Windows had automatically expanded the page file while the helper continued growing

Resource-shape observations:

• Handle count remained around 790-795.
• Thread count remained around 31-33.
• GPU process memory was only about 56 MB.
• Paged/nonpaged kernel pools were not growing in proportion to the helper.
• Most of the retained memory was private user-mode memory.

This pattern appears more consistent with unreleased capture images/frame buffers or another user-mode allocation loop than with a handle leak, thread leak, GPU allocation, or kernel-pool leak. The exact allocation site has not been proven because no memory dump was collected.

What steps can reproduce the bug?

The exact minimal trigger has not yet been isolated, but this was observed with Computer Use enabled:

1. Launch Codex Desktop on Windows.
2. Run a task that starts the bundled Computer Use helper.
3. Leave the Codex session running and monitor codex-computer-use.exe.
4. Observe private bytes and working set increasing continuously instead of returning to a bounded baseline.
5. Continue monitoring until Windows approaches its commit limit and begins paging heavily.

A high-resolution multi-display configuration may amplify the growth rate, but it is not yet known whether it is required.

What is the expected behavior?

• Capture buffers and other per-frame allocations should be released promptly.
• The Computer Use helper should reach a bounded memory baseline.
• An idle, completed, or cancelled Computer Use session should not continue allocating memory.
• The helper should terminate or recover before system commit is exhausted.

Additional information

Windows Event Viewer also recorded repeated ChatGPT.exe Application Error / WER events with exception code 0xc06d007f during the same app session. That may be a separate issue matching #33375 and is included only as a possible co-occurring signal.

Related but distinct reports:

• #33368 tracks accumulation of many helper processes, handles, and threads over multi-day sessions. This report concerns rapid growth inside one codex-computer-use.exe process.
• #33375 tracks repeated serialport.node delay-load failures and the same 0xc06d007f event code.

For privacy reasons, raw session databases, JSONL files, full desktop logs, and process-memory dumps are not attached because they may contain prompts, local paths, credentials, or other session data. Sanitized performance samples can be provided if needed.