macOS 26.810.50856: dozens of ChatGPT Computer Use processes spawn while idle, causing near-100% CPU and severe system lag

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

• #38697
• #37420

Powered by Codex Action

Still reproducible on 26.814.41407 (Aug 18 build) — plus a concrete trigger found in ~/.codex/config.toml

Confirming this bug persists on the latest build. Environment: macOS 26.5.2 (arm64, 8-core), ChatGPT 26.814.41407 (bundled codex-cli 0.148.0-alpha.15), 16 GB RAM.

Observed (same symptoms as reported above):

• After launching the app — even without logging in and without any Codex task — Codex Computer Use processes (mostly SkyComputerUseService under ~/.codex/computer-use/Codex Computer Use.app) spawn and keep accumulating. I counted 71–150 processes.
• System impact: free memory dropped to ~72 MB out of 16 GB, load average hit 449 on an 8-core machine, disk IOPS ~366/s. Whole macOS became unresponsive; user-perceived "freeze" even after logging out.

A concrete trigger I found in ~/.codex/config.toml:

notify = ["/Users/<user>/.codex-internal/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended"]

[mcp_servers.computer-use]
command = "./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient"
args = ["mcp"]
cwd = "."
enabled = false

The notify hook invokes the Computer Use client (SkyComputerUseClient) on turn-ended even though the MCP server itself is enabled = false. When the client fails or hangs, it seems to respawn in a loop → process storm. This also explains why it happens while idle / without the user invoking Computer Use.

Workaround that fixed it for me (no reinstall):

1. Comment out the notify line in ~/.codex/config.toml (back up the file first).
2. Remove ~/.codex/computer-use/ (the component is re-deployed from the app bundle on next launch, but with the notify hook disabled the storm no longer starts).
3. Kill the runaway processes once: pkill -9 -f "computer-use".

Extra note for maintainers: on my machine ~/.codex is a symlink to ~/.codex-internal, and config paths point at the real path — related to #39420.

Please fix the respawn loop on the app side. Happy to provide more logs / diagnostics.

I can confirm this is still present in 26.814.41957 as well. On M3 MBP, 36GiB RAM, running 26.5.2.

最新版好像还是有这个问题，我用别的ai工具强制把computer use禁掉了临时解决了这个问题。

### What version of the Codex App are you using (From “About Codex” dialog)? ChatGPT 26.810.50856 Powered by Codex & OWL Released Aug 15, 2026 ### What subscription do you have? ChatGPT Plus ### What platform is your computer? macOS Sonoma 14.8.9 (arm64) MacBook Pro 14-inch, 2021 Apple M1 Pro 16 GB RAM ### What issue are you seeing? After updating to ChatGPT/Codex 26.810.50856 on Aug 15, 2026, simply launching the app causes extremely high CPU usage and severe system lag, even when no Codex task or Computer Use session is running. Activity Monitor shows dozens of separate ChatGPT Computer Use processes with unique PIDs being spawned while the app is idle. Each instance consumes approximately 4–6% CPU. At the same time, I observed: ChatGPT: ~91% CPU Codex (Renderer): ~49% CPU replayd: ~35% CPU mds_stores: ~58% CPU kernel_task: ~24% CPU elevated tccd, trustd, syspolicyd, XProtectService, and WindowServer CPU idle drops to approximately 0–1%. Memory pressure also increases significantly. On this 16 GB Mac I have observed ChatGPT using approximately 3–4.5 GB RAM, compressed memory reaching 7.61 GB, and swap reaching 6.15 GB. The Mac becomes hot, the Codex UI becomes severely laggy, and the rest of macOS also becomes less responsive. Most importantly, I did not invoke Computer Use. The ChatGPT Computer Use processes appear automatically after launching the app. ### What steps can reproduce the bug? 1. Launch ChatGPT/Codex 26.810.50856 on macOS. 2. Leave the app idle. 3. Do not start a Codex task. 4. Do not invoke Computer Use. 5. Open Activity Monitor and sort by % CPU. 6. Observe that many ChatGPT Computer Use processes with different PIDs begin appearing. 7. CPU usage rapidly increases and macOS system processes such as replayd, tccd, trustd, syspolicyd, mds_stores, and kernel_task also become active. The issue is reproducible immediately after launching the app. ### What is the expected behavior? When ChatGPT/Codex is idle and Computer Use has not been invoked: ChatGPT Computer Use helper processes should not continuously spawn. CPU usage should remain low. Memory and swap usage should remain stable. macOS system services should not be repeatedly triggered. * The Mac should remain responsive and at normal temperature. ### Additional information This behavior started immediately after updating to version 26.810.50856 on Aug 15, 2026. Quitting ChatGPT stops the abnormal process activity. The behavior strongly resembles a ChatGPT Computer Use helper process respawn/restart loop. The many instances shown in Activity Monitor are separate processes with different PIDs, not threads of a single process. I have attached screenshots showing: 1. ChatGPT at ~91% CPU, Codex Renderer at ~49% CPU, and replayd at ~35% CPU. 2. Dozens of simultaneous ChatGPT Computer Use processes with unique PIDs. 3. High memory pressure / compressed memory / swap usage. 4. The affected app version: 26.810.50856. I can provide process samples, spindump, sysdiagnose, or Codex logs if needed. <img alt="Image" width="1383" height="997" src="https://private-user-images.githubusercontent.com/61654255/636494926-d309a159-9e3a-41ce-909e-a2e7b9c3c8b4.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODcyMDQ3MTgsIm5iZiI6MTc4NzIwNDQxOCwicGF0aCI6Ii82MTY1NDI1NS82MzY0OTQ5MjYtZDMwOWExNTktOWUzYS00MWNlLTkwOWUtYTJlN2I5YzNjOGI0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MjAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODIwVDA1NDAxOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTViMjFlYTQ2YmI2NTY4NjY3YmJiMTg3NmYzNTVmMWU5YzE5Mjc3N2Y2OGE1ZTAyNGI5MGQzY2ZjZTMwZWM5ODUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.SK5mGZvyGF_qG0XiKQyw3piJfQfSl5EI_0WFNRdSbzw"> <img alt="Image" width="1383" height="997" src="https://private-user-images.githubusercontent.com/61654255/636494925-d87cf3f3-d5f9-49d2-b920-874e179ee139.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODcyMDQ3MTgsIm5iZiI6MTc4NzIwNDQxOCwicGF0aCI6Ii82MTY1NDI1NS82MzY0OTQ5MjUtZDg3Y2YzZjMtZDVmOS00OWQyLWI5MjAtODc0ZTE3OWVlMTM5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MjAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODIwVDA1NDAxOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWViNjQwZmY2NmFlMTA2YWI1Yzg1ZmIxZWEzNDk0ZDI1NTc5MDQ0NTkzMmMzNTU1NTA5ZThlMDQ3NjcyYmVlOTYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.gQ-OO5JlJXQ2ogBS0I4kSnMKcWi-lYCalVPBQNxKW2g"> <img alt="Image" width="1383" height="997" src="https://private-user-images.githubusercontent.com/61654255/636494924-4ec9e109-5309-4e54-a799-d88b6eb5e21b.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODcyMDQ3MTgsIm5iZiI6MTc4NzIwNDQxOCwicGF0aCI6Ii82MTY1NDI1NS82MzY0OTQ5MjQtNGVjOWUxMDktNTMwOS00ZTU0LWE3OTktZDg4YjZlYjVlMjFiLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MjAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODIwVDA1NDAxOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWVhZDc1YmZjZGRjNDBhNjJmYzQwZmZiNGEwZWFlYmJiMmZlZWMxZDRlYWYyYzNjNmRiNDIyM2Q4YmM4NTExZTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.QP-jPo6DS0HwTMcNqfhXvQpfVG3wSuOfjDBvehC6adA">

I can confirm a closely related failure mode on an earlier Codex desktop build.

Environment:

• ChatGPT/Codex app 26.803.41515, build 6321
• Codex CLI 0.147.0-alpha.6.5
• macOS 15.2 (24C2101), arm64, 16 GB RAM

Observed behavior:

• The app had 12 Computer Use kernels. One node kernel remained runnable for about 30 minutes even though there was no registered active Computer Use execution.
• The affected kernel sustained 131-147% CPU and reached 2.58 GiB RSS.
• A direct open-rollout check attributed the kernel to exactly one live Codex session; the parent Codex process remained healthy enough to continue serving the session.
• The Mac became physically hot while macOS still reported normal thermal pressure.
• The VM volume reached 19 GiB. During a 226-second observation window, the system recorded 814,808 swap-ins and 968,228 swap-outs.

Recovery evidence:

1. Revalidated the exact kernel-to-parent-to-session ancestry.
2. Confirmed the same process start time, three warning samples, no registered active execution, and exactly one rollout held open by the kernel.
3. Sent SIGTERM only to the affected kernel PID.
4. The kernel exited, while the owning Codex process and the chat remained open. The owner then measured about 0.2-3.2% CPU, and the hot kernel did not respawn during the immediate verification window.

This suggests that, in addition to the multi-process spawn loop described in the original report, a single orphaned Computer Use kernel can enter a sustained CPU/RSS loop. A lifecycle cleanup or bounded idle watchdog for unregistered Computer Use kernels may prevent the thermal and swap impact.

I can provide an anonymized process sample or additional metadata if useful.