[macOS] Severe performance regression: 100%+ CPU, 10+ GB RAM usage, and frequent UI hangs

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

• #38455
• #38404
• #38059

Powered by Codex Action

FUCK

[macOS 26.6.1] Codex Desktop spawns hundreds of SkyComputerUseService processes, reaches 11 GiB, and hangs

Summary

Codex Desktop repeatedly spawned hundreds of SkyComputerUseService (Codex Computer Use) child processes within about one minute. Memory usage rose to approximately 10.4–11 GiB, the UI became unresponsive, and macOS generated two hang reports five minutes apart.

The process storm correlated with repeated socket-lock failures and Accessibility/TCC entitlement errors from com.openai.sky.CUAService. Reinstalling the app did not by itself resolve the problem. Renaming the previous Codex state directory and starting with a fresh profile stopped the helper-process storm.

This report does not claim that the external SSD or account/API-key switching is the root cause. The evidence currently points to an unbounded helper restart/spawn loop involving Computer Use runtime state, configuration, lifecycle handling, or an interaction with the helper being located on an external volume.

Environment

• Codex Desktop / ChatGPT app: 26.810.41047 (6570)
• Bundled Codex CLI: 0.148.0-alpha.9
• Codex Computer Use helper: 26.812.1000717 (1000717)
• Helper bundle identifier: com.openai.sky.CUAService
• macOS: 26.6.1 (Build 25G76)
• Architecture: Apple Silicon / arm64
• Hardware: Mac15,7, 36 GB RAM
• Codex state at the time of the incident: /Volumes/OS/.codex on an external APFS SSD
• That state directory has since been renamed to /Volumes/OS/.codex_old
• Login mode recorded in both the old and fresh profiles: ChatGPT account

The external SSD was healthy and responsive during testing: APFS, SMART verified, approximately 511 MB/s sequential read, and a 15,140-node metadata scan completed in 0.89 seconds. This makes simple disk slowness an unlikely explanation for the rapid process explosion.

Impact

• Codex Desktop became unresponsive twice shortly after launch.
• Activity Monitor showed approximately 10.4 GB of memory attributed to ChatGPT/Codex.
• CPU usage reached approximately 105%.
• Hundreds of Computer Use helper processes were created, including dozens of zombie processes.
• The old Codex profile could not be safely reused because launching it risked another process and memory storm.

Incident timeline

First hang

• Start: 2026-08-14 08:52:08.827 +0800
• End: 2026-08-14 08:52:47.026 +0800
• Incident ID: A1E9EDAA-8073-4E6D-B2CA-C7D7F983B93F
• ChatGPT PID: 59199
• Time since process start: 73 seconds
• Main ChatGPT process footprint: 1,641.70 MiB
• Main-process threads: 176
• App unresponsive for 37 seconds
• Dispatch thread soft limit reached: 64

Process snapshot from this report:

• 157 SkyComputerUseService (Codex Computer Use) processes
• Combined helper starting footprint: 4,393.02 MiB
• 52 helper processes marked as zombies
• All helpers were direct children of ChatGPT PID 59199
• Total ChatGPT/Codex-related starting footprint: 7,154.89 MiB across 166 processes

Second hang

• Start: 2026-08-14 08:57:25.347 +0800
• End: 2026-08-14 08:57:52.934 +0800
• Incident ID: 418A392F-0040-48EF-AC6E-63DA43714F29
• ChatGPT PID: 65035
• Time since process start: 83 seconds
• Main ChatGPT process footprint: 3,104.47 MiB
• Main-process threads: 227
• App unresponsive for 22 seconds
• Dispatch thread soft limit reached: 64

Process snapshot from this report:

• 254 SkyComputerUseService (Codex Computer Use) processes
• Combined helper starting footprint: 7,058.75 MiB
• 48 helper processes marked as zombies
• All helpers were direct children of ChatGPT PID 65035
• Total ChatGPT/Codex-related starting footprint: 11,082.47 MiB across 264 processes

The aggregate footprint closely matches the approximately 10.4 GB shown in Activity Monitor.

Sanitized macOS unified-log evidence

Between 08:50 and 08:58, macOS unified logs contained:

• 911 distinct SkyComputerUseService PIDs
• 12,068 socket-lock errors
• 546 distinct helper PIDs that triggered the Accessibility/TCC error below
• An observed helper spawn rate of approximately five processes per second during the captured windows

Repeated socket-lock error:

SkyComputerUseService: socket lock is unavailable errno=35

Repeated Accessibility/TCC error:

TCCDProcess: identifier=com.openai.sky.CUAService ... attempted to call
TCCAccessRequest for kTCCServiceAccessibility without the recommended
com.apple.private.tcc.manager.check-by-audit-token entitlement

The TCC records resolved the helper executable to the external volume:

/Volumes/OS/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/...

Other recurring errors included:

Codex AppServer Thread Events: Error Domain=NSCocoaErrorDomain Code=256
NSUnderlyingError=NSPOSIXErrorDomain Code=9

There were also AppleEvents invalid-right / invalid-capability errors. Network telemetry errors were present but appear secondary and are not the basis of this report.

Hang-stack evidence

Both hang reports show heavily sampled main-thread paths involving V8 interrupt, stack-trace, finalizer, and semaphore-wait operations, including:

v8::CpuProfileNode::GetDeoptInfos
v8::Isolate::RequestInterrupt
v8::Message::GetStackTrace
v8impl::Reference::InvokeFinalizerFromGC
OS_dispatch_semaphore.wait
_dispatch_semaphore_wait_slow
semaphore_wait_trap

The target ChatGPT process sections did not show a direct open, read, SQLite, or APFS stack as the dominant cause of either hang.

Codex log metadata near the hangs

The old profile's logs_2.sqlite contained repeated codex_rmcp_client::stdio_server_launcher activity:

• 288 launcher rows between 08:50 and 08:58
• 36 distinct message shapes
• Four process UUIDs, with 45, 90, 108, and 45 launcher rows respectively
• A new 45-row launcher wave at 08:52:09–08:52:10, immediately after the first hang began
• Another 45-row wave at 08:56:42–08:56:46, shortly before the second hang began at 08:57:25

These figures are metadata counts. No credentials or complete database contents are included here.

Relevant configuration detail

At the time of the incident, the old profile contained:

[plugins."computer-use@openai-bundled"]
enabled = true

[mcp_servers.computer-use]
enabled = false

Other local MCP servers, including node_repl, were enabled.

The fresh profile does not explicitly enable the Computer Use plugin and currently has the Computer Use MCP disabled. With the fresh profile, there are zero persistent SkyComputerUseService processes and no observed spawn storm.

One question is whether plugin enablement can start the helper even when [mcp_servers.computer-use] enabled = false.

Steps that reproduced the incident

The problem reproduced twice during the same incident window:

1. Use an existing Codex profile whose state and Computer Use runtime are located under /Volumes/OS/.codex on an external APFS SSD.
2. The profile has computer-use@openai-bundled enabled, while the computer-use MCP entry is disabled.
3. Launch Codex Desktop.
4. Wait approximately 30–90 seconds.
5. Observe new SkyComputerUseService processes appearing continuously, memory rapidly increasing, and the UI becoming unresponsive.
6. Relaunching the app produced a second process storm and hang.

Renaming the old profile to /Volumes/OS/.codex_old and starting with a fresh profile stopped the storm. I have not re-enabled the old profile because doing so risks another runaway event.

Expected behavior

• Computer Use should use a singleton or otherwise bounded helper-process pool.
• A socket-lock or permission failure should produce one actionable error and use bounded retries with backoff or a circuit breaker.
• Failed and stale helper processes should be reaped.
• Disabling the Computer Use MCP should not cause an uncontrolled Computer Use helper spawn loop.
• If external/removable storage is unsupported for the helper runtime, the app should document or enforce the supported location without entering a restart loop.

Actual behavior

• Hundreds of direct child helpers were created in under two minutes.
• The same lock and TCC errors repeated thousands of times.
• Dozens of zombie helpers accumulated.
• Aggregate memory reached approximately 11 GiB.
• The app hit high CPU usage and became unresponsive.
• The behavior recurred after relaunch.

Control checks

• The old external and current fresh internal copies of the Computer Use executable have the same SHA-256:

d4ca38814cd75989e6a2eb6605c39ad7fbb47bfb34410ef8d2edcda53a262b90

• They have the same helper version and signing identity.
• A fresh profile using the same installed Codex Desktop app does not currently produce the helper storm.
• The external SSD passed basic health and throughput checks.
• Both profiles recorded ChatGPT-account login; no authentication/login event aligned with either hang.

This makes a corrupt helper binary, raw disk throughput, or login-mode switching less likely as the sole cause.

Suspected area, not a confirmed root cause

The strongest current hypothesis is a Computer Use lifecycle/retry bug triggered by persisted plugin/runtime state, possibly amplified by an external-path Accessibility/TCC identity issue or repeated MCP launcher initialization.

The evidence does not establish that moving CODEX_HOME to an external SSD is itself the root cause. It may only expose a missing error boundary, retry limit, or TCC-path handling problem.

Questions for maintainers

1. Why does the parent app continue spawning new SkyComputerUseService processes after socket lock is unavailable errno=35?
2. Is there a maximum retry count, exponential backoff, circuit breaker, or singleton enforcement for this helper?
3. Why are failed helper children not reaped before more helpers are spawned?
4. Does enabling computer-use@openai-bundled override [mcp_servers.computer-use] enabled = false?
5. Is storing the Computer Use runtime under a movable or external CODEX_HOME supported with macOS Accessibility/TCC?
6. Could the native, TCC-sensitive helper be stored in a stable app-support location while user data remains on external storage?

Diagnostic files available

I can provide the following after checking them for personal data:

• ChatGPT_2026-08-14-085255_*.hang
• ChatGPT_2026-08-14-085802_*.hang
• Activity Monitor screenshots showing approximately 105% CPU and 10.4 GB memory
• Additional sanitized process counts and unified-log extracts

I will not upload auth.json, full configuration files containing secrets, raw session JSONL files, or the complete logs_2.sqlite database.

Related reports

• Codex issue #26738: macOS Computer Use memory runaway
• Codex issue #28502: macOS renderer freezes after browser/node_repl auto-start
• Codex issue #28250: Computer Use helper entitlement/provisioning/TCC errors
• Codex issue #32797: repeated MCP/Node process batches and high memory

These issues appear related but do not prove that they share the same root cause.

Privacy note

Usernames, unrelated application activity, tokens, account identifiers, message contents, and other sensitive values have been omitted or sanitized from this report.

Troubleshooting reference

• Official OpenAI Codex troubleshooting documentation

Additional reproduction on macOS Apple Silicon:

• The issue reproduced after rolling back from 26.810.41047 (build 6570) to 26.803.81509 (build 6415).
• On the rolled-back version, a renderer sustained about 106% CPU for approximately 20 minutes and the UI became unresponsive.
• During an active research task, the affected renderer was using about 102% CPU. Sending SIGTERM terminated it, but the app spawned a replacement within seconds, and the replacement immediately reached about 147% CPU. The main app and app-server remained running.
• The research turn continued emitting reasoning events while the UI renderer was unresponsive, with no terminal completion event visible in the desktop log.
• One affected session logged 721 occurrences of ResizeObserver loop completed with undelivered notifications, 11 browser-use native pipe listening events, and 12 BrowserUseThreadConfig entries.
• SkyComputerUseService and multiple node_repl processes were active during the affected session.
• Setting enabled = false for both computer-use and node_repl did not prevent runtime startup. After restart, the app rewrote the node_repl configuration and still spawned the managed Browser/node runtime.

This suggests that killing the renderer is not a durable workaround. The app recreates the renderer/layout loop while a research task is active, and the managed Browser/node runtime is provisioned independently of the user configuration. The regression is also not limited to build 6570.

+1
fuck