›_ Codex Issues
Codex Issues / #37084

[macOS 14.3] CUA service launch crash triggers PiP zombie-process loop

Resolved 💬 3 comments Opened Aug 5, 2026 by Feahter Closed Aug 7, 2026
💡 Likely answer: A maintainer (adams-oai, contributor) responded on this thread — see the highlighted reply below.

Summary

On macOS 14.3, Codex Desktop starts SkyComputerUseService even though the helper declares LSMinimumSystemVersion 14.4. The helper crashes during process initialization. The Desktop PiP bridge then retries about every 1.67 seconds without backoff, and each exited direct child remains a zombie under the main Desktop process.

This can exhaust the per-user process limit during an otherwise idle Desktop session.

Environment

  • Codex Desktop bundle ID: com.openai.codex
  • Desktop version: 26.730.61639, build 6234
  • Computer Use helper: com.openai.sky.CUAService 26.803.1000621, build 1000621
  • macOS: 14.3, build 23D56
  • Apple Silicon

The installed Computer Use helper is byte-identical to the copy bundled with the app. This does not appear to be a corrupted local helper copy.

Reproduction

  1. Use Codex Desktop on macOS 14.3.
  2. Launch the app and leave the Desktop session running.
  3. Observe the Desktop logs and process table.

The loop begins without a user initiated Computer Use action in this session.

Actual behavior

Each cycle follows this sequence:

  1. Desktop logs Refreshing managed Computer Use service for PiP and receives a new process identifier.
  2. The new SkyComputerUseService crashes about 124 ms after launch.
  3. RemoteHostedPIPContent logs CUAService bootstrap failed with NSOSStatusErrorDomain Code -600, procNotFound.
  4. It requests another reconnect and starts another helper about 1.67 seconds later.
  5. The exited helper remains a zombie whose direct parent is the main Desktop process.

Sanitized crash signature:

  • EXC_BAD_ACCESS
  • SIGBUS
  • KERN_PROTECTION_FAILURE
  • faulting initialization frames include map_images_nolock, map_images, dyld4 RuntimeState setObjCNotifiers, and _objc_init

The service has not yet reached its own request handling when it crashes. procNotFound is therefore a consequence of the service being gone, not the initiating error.

Impact

The observed cadence is approximately 0.60 zombies per second, one per retry. The condition eventually blocks creation of new user processes.

Expected behavior

  • Gate Computer Use and PiP on the helper supported OS range, with a clear unsupported version message on macOS 14.3.
  • Reap every failed helper launch.
  • Use bounded exponential backoff and a retry budget for PiP CUA bootstrap failures.

Suggested fixes

  1. Do not launch CUA version 26.803.1000621 below its declared macOS 14.4 minimum, or ship a compatible helper.
  2. Ensure the Electron or native spawn path observes and reaps every helper exit.
  3. Add retry backoff and a circuit breaker to the PiP CUA bootstrap path.
  4. Add a regression test that asserts helper count and zombie count remain stable when bootstrap repeatedly fails.

Workaround

Upgrading macOS to 14.4 or later is the first environment correction to test. Fully quitting Codex clears existing zombies, but reopening it on macOS 14.3 restarts the loop.

View original on GitHub ↗

3 Comments

Chocoer · 22 days ago

Additional confirmed reproduction: macOS 13.7.5, with Computer Use disabled and uninstalled

I can confirm the same failure mode on an older supported Desktop OS. This adds evidence that the native PiP host starts independently of the Computer Use MCP/plugin installation state.

Environment

  • Desktop app version: 26.730.61639, build 6234
  • Computer Use helper: com.openai.sky.CUAService 26.803.1000621
  • macOS: 13.7.5
  • Architecture: Apple Silicon
  • Helper metadata:
  • LSMinimumSystemVersion = 14.4
  • Mach-O LC_BUILD_VERSION minos 14.4

The Desktop application itself launches on this OS, but the bundled helper requires macOS 14.4.

Computer Use was disabled/uninstalled before the controlled reproduction

The following were all confirmed before the cold launch:

  • The computer-use MCP entry was disabled.
  • computer-use-bundled-plugin-auto-install-disabled was true.
  • The user-installed <HOME>/.codex/computer-use directory was absent.
  • No Computer Use plugin cache remained.

The only remaining helper was the copy embedded in the Desktop application bundle.

Cold-start timeline

A fresh Desktop main process started at 09:57:54.

09:58:01.274 RemoteHostedPIPContent started private endpoint host
09:58:03.076 RemoteHostedPIPContent CUAService bootstrap failed:
             NSOSStatusErrorDomain Code=-600
             "procNotFound: no eligible process with specified descriptor"
09:58:03.164 RemoteHostedPIPContent requesting managed CUAService reconnect

The reconnect cycle then repeated approximately every 1.65 seconds.

At 09:58:07, Desktop regenerated the disabled [mcp_servers.computer-use] stanza in config.toml. This shows that removing the MCP registration is not a durable workaround. More importantly, the native sky.node / RemoteHostedPIPContent host had already started before that configuration was regenerated.

Zombie-process evidence

A ten-second sample after the cold start showed:

zombies_before=34
zombies_after=40
delta=6

All zombies had the current Desktop main PID as their direct PPID. Newly created zombie PIDs matched the process identifiers reported by the reconnect log.

PiP gate appears independent of Computer Use availability

Local bundle inspection shows the Remote Hosted PiP host is gated by both:

  • the cuaPIP feature flag; and
  • the hidden computerUseAlwaysHidePictureInPicture setting not being true.

The Computer Use settings UI exposes this as Always hide picture in picture, but disabling or uninstalling Computer Use does not automatically set it. Consequently, the PiP host can continue bootstrapping CUA even when the MCP/plugin is unavailable.

Expected behavior

In addition to the fixes already proposed in this issue:

  1. Do not initialize the CUA-backed PiP host when Computer Use is disabled, uninstalled, or unsupported on the current OS.
  2. Automatically disable the PiP host below the helper's declared minimum OS version.
  3. Keep the PiP availability setting consistent with Computer Use installation/availability state.
  4. Reap every failed helper process and stop retrying after a bounded retry budget.

This reproduction contains no user-initiated Computer Use action; launching Desktop and leaving it idle is sufficient.

vcz-Chan · 21 days ago

Additional independent reproduction and verified workaround

I encountered the same issue, investigated its root cause, and independently reproduced it. I also submitted my findings through the official Codex feedback flow.

Feedback thread ID:
019fd78c-c037-7750-b56f-dbf7048ae528

Additional measurements

During the affected session, I observed 2,360 managed Computer Use PiP service refreshes over 3,896.967 seconds, giving an average interval of approximately 1.652 seconds.

The processIdentifier values reported by the PiP refresh logs matched the resulting zombie PIDs one-for-one. All affected zombie processes had the main ChatGPT process as their direct parent.

Verified workaround

Enabling Always hide picture in picture in the Computer Use settings and fully restarting ChatGPT stopped the leak.

Before applying the workaround, zombies increased at approximately 0.60–0.64 per second. After applying it, the zombie count remained unchanged at 1 → 1 during a subsequent 30-second measurement.

Environment:

  • macOS 14.3 (23D2057)
  • Apple Silicon (arm64)
  • ChatGPT 26.730.61639, build 6234
  • SkyComputerUseService 26.803.1000621
adams-oai contributor · 21 days ago

Thank you for reporting this!

This issue should be resolved in the latest Codex update