›_ Codex Issues
Codex Issues / #26738

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

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

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 ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26458
  • #26293
  • #26327
  • #26362
  • #26415

Powered by Codex Action

chenyh200807 · 2 months ago

Additional findings after further local investigation:

  1. Computer Use was recreated after local disable. After I had previously moved/renamed ~/.codex/computer-use/Codex Computer Use.app, an active bundle reappeared at the same path and launched:
~/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

The bundle identified as com.openai.sky.CUAService with CFBundleVersion=809. Locally, the only durable way I found to keep it disabled was to move the active bundle aside and then place a locked zero-byte placeholder at the original app path (uchg), so the Desktop app/updater could not silently recreate it.

  1. The web-related runaway has a concrete child-process shape. For the BI web thread, the Desktop task starts a local Next.js dev server (next-server v16.2.6). During reproduction, the process tree spawned a very large number of child workers like:
node .../deeptutor/web/.next/dev/build/postcss.js ...

One runaway snapshot showed other matched around 63 GB with nearly 1000 matched processes. In a live reproduction, a single next-server (v16.2.6) process showed a large PostCSS worker/process burst under that same .next/dev/build/postcss.js path. Stopping the Next dev process tree immediately dropped the local matched memory back to a few GB.

This means there are likely two interacting failure surfaces:

  • Codex Desktop / Computer Use / app-server helper lifecycle can recreate or retain helper stacks.
  • A web task launched from a Desktop/Computer Use thread can create a huge descendant process tree, and macOS may attribute much of that pressure to the Codex app group in Force Quit.

Even if the PostCSS worker storm is ultimately a project/Next.js issue, Codex Desktop still needs better supervision here: process-group cleanup, descendant reaping, and memory/process watchdogs for commands launched or controlled from Computer Use/web tasks.

  1. A separate local OpenClaw crash loop was found and ruled out. I found an unrelated launchd job (ai.openclaw.gateway) repeatedly restarting an unconfigured openclaw gateway on port 18789. I unloaded it, killed the process, and quarantined its files. Verification after removal:
launchctl list: no ai.openclaw.gateway
lsof -iTCP:18789: no listener
command -v openclaw: no executable in PATH

After removing OpenClaw and stopping the residual Next dev server, my Codex-related matched snapshot returned to roughly 2.8 GB, with no active SkyComputerUse, no OpenClaw, and no postcss.js worker storm.

  1. Important note for diagnostics: raw launchctl print output can include inherited environment variables and should not be requested/pasted publicly without redaction.

These findings do not make this a pure Next.js bug or a pure local-machine issue. They narrow the trigger: Desktop + Computer Use/web-task execution can leave or recreate high-risk helper/descendant process trees, and there is currently no effective user-facing hard-disable or watchdog boundary for Computer Use.

chenyh200807 · 2 months ago

Additional evidence from the same macOS host, after another Web/BI task triggered memory pressure today. This suggests the reproducible risk is not only Computer Use itself, but also long-running Web dev servers owned by agent process trees.

Sanitized timeline:

  • 2026-06-06 19:36 +0800: macOS wrote JetsamEvent-2026-06-06-193602.ips.
  • Terminal coalition contained 3,954 processes, including 3,927 node processes.
  • Terminal coalition resident pages summed to about 201.6 GB, lifetime max about 216.3 GB.
  • Compressor size was about 24.36 GB and free memory was effectively exhausted.
  • A user crash report for node at the same time showed coalitionName: com.apple.Terminal, responsibleProc: Terminal, and a memory-pressure SIGKILL-style termination.
  • The active parent chain observed immediately after the spike was: claude --dangerously-skip-permissions -> shell -> node ... next dev -p 3737 -> next-server (v16.2.6).
  • Earlier in the same investigation, the same class of Next/PostCSS process tree was observed under /Applications/Codex.app/Contents/Resources/codex app-server.

Local conclusion so far:

  • macOS app memory shown as Codex/Terminal can be a coalition total from thousands of agent-owned child node workers, not just the GUI process itself.
  • Computer Use / Codex helper lifecycle still appears to be one trigger, but Web/BI work that lets an agent own next dev can independently reproduce the same failure shape.
  • --max-old-space-size did not protect the machine because it only limits one Node process, not thousands of child workers.

Local mitigation added:

  • Disabled Computer Use locally.
  • Added a guard that detects and kills next dev, next-server, and .next/dev/build/postcss.js process trees when their ancestor is Codex app-server or Claude Code.
  • New local rule: do not let Codex Desktop / Computer Use / Claude Code own long-running Next dev servers; run them in a separately supervised terminal/tmux session and stop them after the task.

This may help triage whether Codex Desktop needs stricter child-process supervision / cleanup for agent-owned Web dev server trees, in addition to the Computer Use lifecycle issue originally reported.

jackychanisnotme · 1 month ago

Additional reproducible evidence from a separate Mac, on a newer Desktop/Computer Use build. This appears to be a concrete in-process XPC object leak, not only memory attributed from agent-owned descendants.

Environment

  • ChatGPT/Codex Desktop: 26.721.41059 (build 5848)
  • SkyComputerUseService: 26.721.1000502 (build 1000502)
  • macOS: 26.5.1 (25F80), Apple Silicon, 16 GB RAM

Live observations

  • Two SkyComputerUseService instances reached approximately 4.2 GB physical footprint each, sustaining 64-84% CPU each.
  • The main Desktop process reached approximately 6.9 GB physical footprint and 65-70% CPU.
  • Swap usage reached approximately 9.0 / 10 GB.
  • Each Desktop instance spawned its own Computer Use service, directly multiplying the failure.

Heap evidence from one SkyComputerUseService instance

heap -s -H --showSizes <pid> reported 33,214,621 live malloc nodes / 4.0 GB, dominated by:

  • 8,289,701 xpc_dictionary_t objects: approximately 2.0 GB
  • 8,289,701 OS_xpc_payload objects: approximately 506 MB
  • 16,579,867 unidentified 96-byte allocations: approximately 1.5 GB

The matching counts strongly suggest an unbounded XPC request/reply retention cycle.

CPU sample

The hot path repeatedly queried:

NSRunningApplication.bundleIdentifier/localizedName
→ _LSCopyApplicationInformation
→ LSClientToServerConnection::sendWithReply

During this loop, macOS launchservicesd itself sustained approximately 27-36% CPU. This seems related to #26415, but here it also produces a deterministic multi-GB XPC heap leak.

The Desktop process was simultaneously hot in RemoteHostedPIPContentService connectToEndpoint:rendezvousPort: through sky.node and NSXPCConnection.

Crash and Jetsam correlation

Six recent Desktop crash reports, all from build 26.721.41059 (5848), terminated with EXC_BREAKPOINT / SIGTRAP. The faulting paths consistently involved NSXPCConnection endpoint handling or RemoteHostedPIPContentService. The most recent occurred on July 28, 2026 at 12:03 +0800.

Two macOS Jetsam reports on July 26 identified SkyComputerUseService as the largest process. In one event it had approximately 9.6 GiB resident memory.

Likely failure chain

  1. Computer Use enters a tight running-application enumeration / LaunchServices XPC loop.
  2. XPC dictionaries and payloads are retained without bound.
  3. Multiple Desktop instances multiply the leak.
  4. Severe memory pressure and swap activity follow.
  5. The Desktop app eventually traps in the RemoteHostedPIP/XPC bridge.

No raw crash reports or user-specific paths are included here; all values above are from read-only, sanitized local diagnostics.

mrtomatwo · 23 days ago

Confirmation from a separate Apple Silicon Mac on a newer Desktop/Computer Use build.

Environment:

  • ChatGPT/Codex Desktop: 26.727.51351 (build 6119)
  • Codex Framework: 150.0.7871.182
  • SkyComputerUseService: 26.727.1000550
  • macOS: 26.6 (25G72), arm64

Observed on 2026-08-04:

  • Six ChatGPT crash reports in one day, all EXC_BREAKPOINT / SIGTRAP.
  • The faulting paths consistently involve NSXPCConnection endpoint handling or RemoteHostedPIPContentService; the latest traps in connectToEndpoint:rendezvousPort: on CrBrowserMain.
  • Crash voucher attribution identifies SkyComputerUseService.
  • Two separate Desktop profiles were running concurrently, each with its own SkyComputerUseService consuming approximately 88% CPU.
  • A one-second sample of the hot helper showed the same loop described above: NSRunningApplication.localizedName/bundleIdentifier -> _LSCopyApplicationInformation -> LSClientToServerConnection::sendWithReply.
  • Multiple stale helper processes remained after earlier Desktop crashes.
  • The crash report does not indicate EXC_RESOURCE/OOM, a code-signing failure, or external process modification; the Desktop app deliberately traps in the RemoteHostedPIP/XPC bridge.

This closely reproduces the failure chain documented in the July 28 comment, including the multiplier from multiple Desktop instances, and confirms that it persists in build 26.727.51351 / Computer Use 26.727.1000550.

I can provide a redacted .ips report and CPU sample through a private channel if useful.

boombx403-byte · 9 days ago

Hi @chenyh200807, that rollout size is valuable stress evidence. Codex Rescue Alpha5 scans large local session histories with bounded memory and produces aggregate size, media, and compaction diagnostics without loading the whole file into RAM or dumping full payloads.

If you still have an affected closed rollout, you can test it locally:

pip install codex-rescue==0.1.0a5
codex-rescue doctor <path-to-rollout.jsonl>

No raw session upload is needed; sanitized aggregate output is sufficient.