Intel macOS: Computer Use startup fails after 26.803.61601 (250 ms native-pipe timeout; managed helper absent)
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.5k
- PR merge metrics
- PR metrics pending
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the desktop app's managed Computer Use startup path and the @oai/sky sky.list_apps() entry point; inspect how the darwin-x64 bundle discovers the helper and handles the 250 ms ping timeout. Compare the bundled helper, plugin, runtime, and compatibility skill bootstrap during the @oai/cua-to-@oai/sky transition. Done means Intel startup succeeds with authorization preserved, or explicitly reports unsupported Intel, with a regression covering delayed peer authorization.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, macos, node.js
- Domain
- desktop, security
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100