Repository navigation
Codex Desktop Computer Use can trigger memory runaway to 172GB on macOS #26738
Description
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.40724CFBundleVersion: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 GBDocker Desktop: 6.47 GBWeChat DevTools: 2.07 GBTerminal: 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:
- Open Codex Desktop.
- Resume an existing long-running Desktop thread.
- 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.
- Ask the thread to continue.
- Codex starts or restores Computer Use and helper processes.
- 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_replMCP entry inconfig.toml - config was locked locally with
uchgto 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:
- Quit Codex Desktop and kill stale helper processes.
- Move large rollout JSONL files out of active
~/.codex/sessionsrather than deleting them. - 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>
- 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
Activity
github-actions commentedon Jun 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
chenyh200807 commentedon Jun 6, 2026
Additional findings after further local investigation:
~/.codex/computer-use/Codex Computer Use.app, an active bundle reappeared at the same path and launched:The bundle identified as
com.openai.sky.CUAServicewithCFBundleVersion=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.next-server v16.2.6). During reproduction, the process tree spawned a very large number of child workers like:One runaway snapshot showed
other matchedaround 63 GB with nearly 1000 matched processes. In a live reproduction, a singlenext-server (v16.2.6)process showed a large PostCSS worker/process burst under that same.next/dev/build/postcss.jspath. 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:
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.
launchdjob (ai.openclaw.gateway) repeatedly restarting an unconfiguredopenclaw gatewayon port18789. I unloaded it, killed the process, and quarantined its files. Verification after removal: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 nopostcss.jsworker storm.launchctl printoutput 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 commentedon Jun 6, 2026
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:
JetsamEvent-2026-06-06-193602.ips.nodeprocesses.nodeat the same time showedcoalitionName: com.apple.Terminal,responsibleProc: Terminal, and a memory-pressure SIGKILL-style termination.claude --dangerously-skip-permissions-> shell ->node ... next dev -p 3737->next-server (v16.2.6)./Applications/Codex.app/Contents/Resources/codex app-server.Local conclusion so far:
nodeworkers, not just the GUI process itself.next devcan independently reproduce the same failure shape.--max-old-space-sizedid not protect the machine because it only limits one Node process, not thousands of child workers.Local mitigation added:
next dev,next-server, and.next/dev/build/postcss.jsprocess trees when their ancestor is Codex app-server or Claude Code.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 commentedon Jul 28, 2026
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
26.721.41059(build5848)SkyComputerUseService:26.721.1000502(build1000502)26.5.1 (25F80), Apple Silicon, 16 GB RAMLive observations
SkyComputerUseServiceinstances reached approximately 4.2 GB physical footprint each, sustaining 64-84% CPU each.Heap evidence from one SkyComputerUseService instance
heap -s -H --showSizes <pid>reported 33,214,621 live malloc nodes / 4.0 GB, dominated by:xpc_dictionary_tobjects: approximately 2.0 GBOS_xpc_payloadobjects: approximately 506 MBThe matching counts strongly suggest an unbounded XPC request/reply retention cycle.
CPU sample
The hot path repeatedly queried:
NSRunningApplication.bundleIdentifier/localizedName→
_LSCopyApplicationInformation→
LSClientToServerConnection::sendWithReplyDuring this loop, macOS
launchservicesditself 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:throughsky.nodeandNSXPCConnection.Crash and Jetsam correlation
Six recent Desktop crash reports, all from build
26.721.41059 (5848), terminated withEXC_BREAKPOINT / SIGTRAP. The faulting paths consistently involvedNSXPCConnectionendpoint handling orRemoteHostedPIPContentService. The most recent occurred on July 28, 2026 at 12:03 +0800.Two macOS Jetsam reports on July 26 identified
SkyComputerUseServiceas the largest process. In one event it had approximately 9.6 GiB resident memory.Likely failure chain
No raw crash reports or user-specific paths are included here; all values above are from read-only, sanitized local diagnostics.
mrtomatwo commentedon Aug 4, 2026
Confirmation from a separate Apple Silicon Mac on a newer Desktop/Computer Use build.
Environment:
26.727.51351(build6119)150.0.7871.18226.727.100055026.6 (25G72), arm64Observed on 2026-08-04:
EXC_BREAKPOINT / SIGTRAP.NSXPCConnectionendpoint handling orRemoteHostedPIPContentService; the latest traps inconnectToEndpoint:rendezvousPort:onCrBrowserMain.SkyComputerUseService.SkyComputerUseServiceconsuming approximately 88% CPU.NSRunningApplication.localizedName/bundleIdentifier->_LSCopyApplicationInformation->LSClientToServerConnection::sendWithReply.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 Use26.727.1000550.I can provide a redacted
.ipsreport and CPU sample through a private channel if useful.boombx403-byte commentedon Aug 18, 2026
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:
No raw session upload is needed; sanitized aggregate output is sufficient.
saffadev commentedon Sep 4, 2026
Additional reproduction on current ChatGPT/Codex Desktop build
I am seeing what appears to be the same severe memory-runaway issue on a substantially newer ChatGPT desktop build.
Environment
26.901.22334, build7746com.openai.codex26.6.2(25G83), arm64Observed failures
I have now reproduced the failure three times:
Baseline before reproduction
After reboot, swap returned to
0and system memory pressure was normal.Before the latest reproduction, the complete
/Applications/ChatGPT.appprocess tree was approximately 2.28 GB RSS, the largest individual process was approximately 485 MB, and swap was 0.Activity Monitor also showed
ChatGPT Computer Useresident at approximately 26 MB. The presence of that helper alone did not cause immediate growth; the app was stable at baseline before the development/build workflow triggered the failure.Reproduction pattern
Normal ChatGPT usage appeared stable before this trigger. The latest failure occurred shortly after the app was measured at ~2.28 GB aggregate RSS with zero swap, after which macOS Force Quit reported ChatGPT at 79.69 GB.
I have stopped further reproduction attempts because each incident makes the 16 GB machine effectively unusable.
I have Activity Monitor / Force Quit screenshots showing the ~70 GB, ~82 GB, and ~80 GB incidents and can provide additional diagnostics if useful.
saffadev commentedon Sep 4, 2026
Follow-up: XcodeBuildMCP appears to be a concrete trigger in this reproduction
I captured a more specific process snapshot during the affected iOS workflow.
Immediately before this, ChatGPT/Codex reported that it had used the XcodeBuildMCP integration. The simulator was ready, but the build encountered a stale/concurrent Xcode build database lock from an earlier test attempt. Codex then checked for an active build and retried using a separate DerivedData location.
During that workflow, the process snapshot showed two simultaneous XcodeBuildMCP generations plus an active
xcodebuild:At that instant:
The important part is that there were two independently launched XcodeBuildMCP server/process trees alive at the same time. One of those trees owned the active
xcodebuildprocess.After terminating the XcodeBuildMCP/xcodebuild tree, no Xcode build processes remained, but the machine still had very high swap usage and required a reboot to return to a clean baseline.
This appears consistent with the MCP helper/process lifecycle behavior discussed in #17574: repeated or concurrent MCP helper generations can accumulate instead of being reliably reaped when a task retries or changes execution paths.
This does not by itself prove that XcodeBuildMCP is responsible for all memory attributed to ChatGPT/Codex, but it gives a concrete trigger and process topology for this reproduction.
saffadev commentedon Sep 4, 2026
Follow-up after further isolation of the iOS build memory issue:
We identified a project-specific contributor that explains the extreme Swift compiler memory usage observed during direct Xcode builds, separate from the Codex/XcodeBuildMCP process-lifecycle behavior reported above.
The project contained an auto-generated Swift source file of approximately 43,700 lines / 3.7 MB, with a large dataset represented as a static Swift array literal.
We reproduced the compiler memory problem outside Codex using direct
xcodebuild. DuringEmitSwiftModule,swift-frontendconsumed several GB of memory and drove the machine heavily into swap.Isolation testing showed:
This establishes that the extreme
swift-frontendmemory growth during direct builds was caused by the large generated Swift literal and should not be attributed to Codex/XcodeBuildMCP.However, the separate Codex behavior originally reported remains relevant. During the Codex-triggered workflow we observed two simultaneous XcodeBuildMCP server generations as well as orphaned/reparented build/compiler processes. That behavior is independent of the generated-source compiler issue.
We have since switched to using the XcodeBuildMCP CLI workflow rather than running XcodeBuildMCP as a persistent MCP server.
Hopefully this distinction is useful: a project-specific Swift compiler issue significantly amplified memory pressure, but it does not explain the duplicate MCP helper/process-lifecycle behavior observed during the Codex workflow.
hanswembacher commentedon Sep 8, 2026
Independent reproduction: cron-created Desktop tasks leak full MCP/helper stacks
I reproduced the same failure on a separate 128 GB Apple Silicon Mac. The additional detail in this reproduction is a deterministic five-minute automation cadence and macOS Jetsam coalition accounting that identifies the accumulated process classes.
Environment
26.901.51231, build810926.6.2(25G83), Apple Silicon Mac17,6com.openai.codex; executable path ends inCodex.app/Contents/MacOS/ChatGPTDeterministic reproduction
Jetsam evidence
On 2026-09-04 the ChatGPT/Codex jetsam coalition reached approximately 173.7 GB. Grouped resident-page accounting (
rpages * 16 KiB) showed:nodeprocesses: 48.6 GBpython3processes: 49.8 GBnode_replprocesses: 5.1 GBcodex app-server: 28.3 GBOn 2026-09-07, after a restart and another accumulation cycle, the same coalition reached approximately 160.1 GB:
nodeprocesses: 56.5 GBpython3processes: 38.3 GBnode_replprocesses: 8.1 GBcodexprocesses: 26.2 GBThe relevant Jetsam reason was
vm-compressor-space-shortage. The visible GUI process itself was only around 0.3–0.4 GB; the Force Quit value was the app coalition total.The process start times track the five-minute automation schedule exactly. After pausing the automation and terminating only the stale Unified Computer Use launchers,
node_replinstances, and OpenKnowledge STDIO MCP helpers, the local Codex/helper RSS returned from 5.7 GB with 61 remaining helpers to 3.2 GB with two helpers. Disabling automatic startup for those local tools prevented immediate recreation.Two separately loaded local
llama-servermodels increased system pressure but were outside the Codex coalition and therefore do not explain the 160–174 GB attributed to Codex.Expected behavior
I can provide redacted excerpts of the macOS Jetsam reports privately if needed.