Intel macOS: Computer Use startup fails after 26.803.61601 (250 ms native-pipe timeout; managed helper absent)
OpenAI feedback thread
019ff0ed-18c7-7983-a939-09d9e861e0ec (submitted with no diagnostic-log upload)
What version of the Codex App are you using?
ChatGPT/Codex desktop 26.803.61601 (build 6396), with a valid OpenAI Developer ID signature.
Bundled runtime:
@oai/sky 0.6.6cua_nodeNode24.14.0- target
darwin-x64
What subscription do you have?
Not included in this public report.
What platform is your computer?
macOS 14.8.8 (23J620), Intel x86_64.
What issue are you seeing?
Computer Use could not initialize after the desktop update.
The app log reported:
Failed to reconcile managed Computer Use service
Failed to spawn managed Computer Use service
Two direct calls through the currently bundled package:
await (await import("@oai/sky")).sky.list_apps()
both failed with:
Sky Computer Use service startup request failed
Screen Recording, Accessibility, event-post, and event-listen permissions were granted, and the console session was unlocked.
The signed x86_64 app bundle contains @oai/sky, but it does not contain:
Codex Computer Use.app- a bundled
computer-useplugin - the older
@oai/cuapackage
This leaves the managed-service fallback with no helper payload to spawn.
Steps to reproduce
- Install/update the Intel macOS desktop app to
26.803.61601. - Enable Computer Use and grant Screen Recording and Accessibility.
- Fully relaunch the desktop app.
- Invoke Computer Use or call
sky.list_apps(). - Observe
Sky Computer Use service startup request failed. - Inspect the signed x86_64 app resources and observe that the managed helper/plugin payload is absent.
Expected behavior
Computer Use should initialize and list/capture approved apps on a supported Intel Mac after permissions are granted. If Intel is no longer supported, the app should report that explicitly instead of installing a darwin-x64 runtime that falls through to a missing managed service.
Root cause found locally
The @oai/sky 0.6.6 native-pipe path gives the first connect-and-ping attempt a 250 ms budget.
A local Intel compatibility service performs Security.framework peer validation before handling requests:
- same UID
- peer PID
- OpenAI Team ID
2DC432GLL2 - expected signed Codex/Node identity and trusted ancestor
A real ping took 287 ms. The client therefore timed out, invoked the host's managed-service path, and then failed because this x86_64 build has no managed helper to spawn.
Local compatibility repair
The repair preserved authorization for every operation and changed only the harmless handshake path:
- Parse only the first framed JSON-RPC message.
- If it is a valid
CodexComputerUseIPC-2ping, immediately returnserverApiVersion. This response exposes no app data and performs no action. - Pause and buffer all remaining frames.
- Run the unchanged Security.framework fd-peer authorization.
- Process list/state/action requests only after authorization succeeds.
- If the first message is not a ping, keep it buffered and authorization-gated for backward compatibility.
- Update the compatibility skill bootstrap from the removed
@oai/cuaplusinitialize()path to:
globalThis.sky ??= (await import("@oai/sky")).sky;
No authentication, app-policy, screenshot, or input-event check was bypassed.
Validation after the repair
- A deterministic regression delays peer authorization by 600 ms while requiring the ping response within 250 ms.
- Source and installed plugin-cache suites: 16/16 tests passed.
- Real ping latency: 287 ms before, 25 ms after.
- The official bundled
@oai/skyclient returned six valid app IDs fromlist_apps(). - A read-only Finder
get_app_statereturned a file screenshot and 12,351 characters of accessibility text. - No click or keyboard input was used, and the temporary screenshot was removed.
Suggested product fixes
- Bundle and sign an x86_64 or universal
Codex Computer Use.appplus thecomputer-useplugin in the Intel desktop build, or make the managed-service path discover an already-running compatible service. - Increase the initial direct-connect/ping budget above realistic code-signing verification latency, or explicitly support a data-free unauthenticated ping followed by authenticated request processing.
- Keep the helper payload, plugin catalog, runtime package, and bundled skill/docs consistent when moving from
@oai/cuato@oai/sky. - Preserve the nested startup cause in the user-visible error.
2 Comments
Nice investigation! Would be nice to FINALLY have Computer Use available on Intel Macs. Come on, OpenAI, can't you just ask Codex to fix it once and for all?!
Confirming this still reproduces in the newer Intel build and now affects the Computer History opt-in flow, not only direct Computer Use/Appshots.
Environment
26.810.41047(build6570)14.7.8(build23H730)x86_64@oai/sky:0.6.11Observed behavior
Computer History appears under Settings and the account/feature gate is enabled, but selecting Turn on does not start it. The app logs:
The worker also reports the same failure for
skysightStart.The Intel app bundle contains
@oai/sky, but itsbindirectory is empty and the expected helper is absent:The canonical per-user location also has no helper application; it contains only the Computer Use configuration file.
This means the current UI treats the Intel Mac as eligible and exposes the Computer History toggle, but the required managed service cannot be spawned.
Expected behavior
Either:
This confirms the missing-helper failure persists in
26.810.41047.