›_ Codex Issues
Codex Issues / #26738

Codex Desktop Computer Use can trigger memory runaway to 172GB on macOS

Open 💬 3 comments Opened Jun 6, 2026 by chenyh200807

Summary

Codex Desktop on macOS can enter a severe memory runaway state when a Desktop thread uses or restores Computer Use. In my latest incident, macOS Force Quit Applications reported Codex at 172.68 GB. The machine became effectively unusable and previously similar incidents caused system crashes/restarts.

This is reproducible enough that I have stopped using the affected Desktop threads. The strongest trigger is resuming a long-running Codex Desktop thread that improves a BI web page and invokes Computer Use. When I ask that thread to continue, Codex almost immediately freezes the machine or drives memory into a system-level exhaustion state.

Environment

  • Hardware: Apple Silicon MacBook Pro, 64 GB RAM
  • macOS: 26.5.1, build 25F80
  • Architecture: arm64
  • Codex Desktop app:
  • CFBundleShortVersionString: 26.602.40724
  • CFBundleVersion: 3593
  • bundle id: com.openai.codex
  • Codex runtime reported by binary: Codex 149.0.7827.54
  • Codex CLI: codex-cli 0.137.0
  • Locale: zh-Hans-CN

What happened

The most severe observed incident:

  • macOS displayed the "Force Quit Applications" memory warning.
  • It reported:
  • Codex: 172.68 GB
  • Docker Desktop: 6.47 GB
  • WeChat DevTools: 2.07 GB
  • Terminal: 1.87 GB
  • This is far beyond available physical memory and caused system-level pressure.

I had already upgraded from a 16 GB machine to a 64 GB machine because this class of issue was making the old machine unusable. The issue still happens on 64 GB RAM, so this does not look like normal resource usage or an undersized machine.

Reproduction pattern

The most reliable trigger:

  1. Open Codex Desktop.
  2. Resume an existing long-running Desktop thread.
  3. The thread's task is to improve a BI web page and use Computer Use / desktop control to inspect or interact with the web UI.
  4. Ask the thread to continue.
  5. Codex starts or restores Computer Use and helper processes.
  6. The machine quickly becomes unresponsive or memory grows to tens of GB; the worst observed Force Quit reading was 172.68 GB for Codex.

I also saw related memory/helper buildup in another Desktop thread that was only doing workspace cleanup / commit-style work, which suggests the leak may involve Desktop thread restoration, helper lifecycle, local history loading, or app-server state, not only the visible Computer Use action itself.

Diagnostics

Before mitigation, process snapshots repeatedly showed duplicated or recreated helper trees under Codex Desktop app-server, including:

/Users/.../.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
/Applications/Codex.app/Contents/Resources/node_repl
node ./mcp/server.bundle.mjs
node ./mcp/server.cjs --stdio
node ./mcp/server.mjs
codegraph.js serve --mcp
context7-mcp
@playwright/mcp / playwright-mcp in earlier sessions

codex doctor --summary --ascii before history mitigation reported:

rollouts 1,539 active files · 9.98 GB on disk
threads  2 issues - rollout files are missing from the state DB; state DB rows point at missing or unusable rollout files
mcp      1 server (1 streamable_http)

After moving 33 rollout JSONL files larger than 50 MB out of ~/.codex/sessions, codex doctor reported:

rollouts 1,501 active files · 5.54 GB on disk
threads  2 issues - rollout files are missing from the state DB; state DB rows point at missing or unusable rollout files
mcp      1 server (1 streamable_http)

The state databases were reported healthy.

Important configuration detail

This still occurred after reducing local Codex configuration to a low-memory setup:

  • notify = []
  • active MCP config only included GitHub streamable HTTP
  • Browser plugin disabled
  • context7 disabled
  • no active node_repl MCP entry in config.toml
  • config was locked locally with uchg to prevent automatic rewrites

Despite that, the already-running Desktop session could still recreate:

node_repl
node ./mcp/server.bundle.mjs
node ./mcp/server.cjs --stdio
node ./mcp/server.mjs
SkyComputerUseService

Computer Use was also recreated after I renamed its app bundle once, requiring a second disable action.

Local mitigation that helped

These mitigations reduced the current machine from system-exhaustion state to a stable few GB, but they are workarounds:

  1. Quit Codex Desktop and kill stale helper processes.
  2. Move large rollout JSONL files out of active ~/.codex/sessions rather than deleting them.
  3. Rename Computer Use app bundle so it cannot start:
~/.codex/computer-use/Codex Computer Use.app
-> ~/.codex/computer-use/Codex Computer Use.app.disabled-<timestamp>
  1. Kill leftover helpers:
node_repl
node ./mcp/server.bundle.mjs
node ./mcp/server.cjs --stdio
node ./mcp/server.mjs
SkyComputerUseService

After final cleanup, the local snapshot was around 2-3 GB matched Codex/helper processes with no visible SkyComputerUse, node_repl, or postcss.js processes.

Expected behavior

  • Computer Use should not cause Codex Desktop to consume tens or hundreds of GB of memory.
  • Closing or stopping a Desktop task should reliably reap Computer Use / MCP / node helper processes.
  • Resuming a long thread should not load or retain enough local history/helper state to exhaust system memory.
  • Disabled or absent MCP config entries should not lead to repeated helper recreation unless the user explicitly invokes the corresponding capability.

Actual behavior

  • Using or restoring Computer Use in a long Desktop thread can make Codex immediately freeze the machine.
  • macOS Force Quit showed Codex at 172.68 GB.
  • Helper process trees are recreated under the Desktop runtime even after low-memory config.
  • Renaming/disabling Computer Use and moving large rollout history out of active sessions are currently the only practical local mitigations I found.

Related observation

Some node processes in Activity Monitor were unrelated Next/PostCSS frontend workers from my project, but those were distinguishable by command line (web/.next/dev/build/postcss.js) and exited when their parent build process exited. The Codex-specific persistent/recreated helpers were node_repl, node ./mcp/server.*, and SkyComputerUseService.

Request

Please treat this as a new active Codex Desktop / Computer Use memory runaway report, not only as a duplicate of older closed helper-leak issues. The Computer Use trigger is important: when a thread uses Computer Use, the system can become unusable almost immediately.

Useful fixes would likely include:

  • stricter Computer Use process lifecycle management and process-group cleanup
  • a hard memory/process watchdog for Computer Use and app-server helper trees
  • no automatic recreation of Computer Use/helper stacks unless explicitly invoked
  • lazy/streamed local rollout loading instead of retaining very large JSONL history in memory
  • a user-facing setting or config key that truly disables local Computer Use helper startup

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗