Intel macOS: is there a supported official Computer Use MCP or native-provider integration path?

Request

Could the Codex team clarify the supported way, if any, to use the official Computer Use MCP and native execution runtime on an Intel Mac?

The underlying missing-helper reports are already tracked in #42514, #31160 and #18404. This question focuses on the integration contract: whether the official MCP is independently distributable, whether an Intel-compatible client/service exists, and whether a local native provider can be integrated through a supported authorization and cancellation interface. The evidence below explains why simply adding the official MCP configuration has not worked. Please consolidate this into an existing thread if preferred.

My goal is reliable desktop-app operation without taking over my physical pointer or changing the foreground application. Locked Use is a separate capability for which I also need a clear support statement. A browser-only MCP connection or a limited custom automation tool is not equivalent to that experience.

Questions for maintainers

1. Support matrix: Are native Computer Use, background desktop input, and Locked Use supported on Intel macOS? Please distinguish these capabilities from support for the desktop app itself and browser automation. If Intel native support is planned rather than available, is there a tracking issue?
2. Official MCP access: Is there an official standalone distribution of SkyComputerUseClient and its matching native service with x86_64 or Universal binaries? Alternatively, is there a supported remote transport/provider endpoint? If so, please identify the installation, authentication and host requirements, including which computer's desktop is actually controlled. I have not found a verified public distribution or endpoint; I am not claiming none can exist.
3. Local provider contract: If the official native runtime cannot currently run on Intel, is there a supported way to register a local native provider under its own identity while retaining the official client's app-policy checks, approvals, active-turn authorization, interruption and cleanup? I am not asking to impersonate an official marketplace, fabricate an OpenAI signature, override a disabled surface, or bypass lock-screen protections. If this is not an extension point, please document that explicitly.
4. Contribution path: Which public repository/build target, if any, owns the native helper packaging or the relevant host integration? I am willing to help with a narrowly scoped PR and Intel testing. If those components are not public, would the team accept a packaging-validation or diagnostics contribution elsewhere?

Tested environment and scope

Local diagnostics were performed on my Intel machine with assistance from a local Codex session.

• Architecture: x86_64.
• macOS: 26.6.2.
• Desktop build tested: 26.901.51231, installed as /Applications/ChatGPT.app.
• Bundled @oai/sky: 0.6.26.
• These observations are tied to the tested build; I am not asserting that it is the latest release at the time this issue is read.

Evidence: the Intel distribution lacks the required payload

The unmodified installed desktop app passed:

codesign --verify --deep --strict /Applications/ChatGPT.app

The installed Contents/Resources/native/sky.node is an OpenAI-signed x86_64 module, but the native helper app is absent from both locations used by the inspected host:

/Applications/ChatGPT.app/Contents/Resources/cua_node/lib/node_modules/@oai/sky/Codex Computer Use.app
$CODEX_HOME/computer-use/Codex Computer Use.app

The expected executable is:

Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

Application/plugin-cache searches found no service, and the application's CodeResources manifest did not contain it. To distinguish this from damage to an installed copy, the full ZIP central directory of the official ChatGPT-darwin-x64-26.901.51231.zip was parsed using HTTP Range: 7,952 entries, with the parsed count matching the EOCD record. It contained no corresponding service entries. The inspected beta x64 26.727.40816 archive also lacked the helper.

The desktop startup failure was:

Failed to spawn managed Computer Use service

The bundled Intel Node runtime can load sky.node; that alone did not provide a complete standalone desktop list/state/input interface.

Evidence: the official MCP launcher stops before initialization

The same-version official ARM archive contains plugins/openai-bundled/plugins/computer-use/. Its .mcp.json uses:

command: ./bin/computer-use-client-launcher
args: [mcp]

The original launcher resolves to:

$CODEX_HOME/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp

Invoking the unchanged launcher from the isolated extracted plugin on Intel exits with status 1, reporting client was not found. No MCP initialize exchange occurs. This is not a tool-discovery or MCP handshake timeout.

The real SkyComputerUseClient executable was extracted by ZIP entry from the official ChatGPT-darwin-arm64-26.901.51231.zip and its CRC checked against the archive:

Size:    14,026,784 bytes
SHA-256: 5e0d0824d0e1486d531326ee4ca07315089e6648be866f2fef22873cdb7711fe
file/lipo: thin arm64, no x86_64 slice

It was inspected, not executed. The matching service and the inspected Locked Use components (CUALockScreenGuardian, the authorization-plugin executable, and InstallerTool) were also arm64-only; the same named components were absent from the Intel installation. The ARM artifacts are comparison evidence, not an Intel workaround.

Evidence: unified MCP availability is browser-only here

codex plugin list --available --json listed unified-computer-use, but no separate computer-use entry in the directories it considered. The installed unified runtime is exposed through cua_repl; the host-generated configuration was:

CUA_REPL_ENABLED_SURFACES=browser
trustedServices: browser only

Inspection of this build's computer path leads to @oai/sky and the local macOS service. I did not find a supported remote-provider argument in the inspected mac client factory. I have not modified these surfaces or trusted-service settings.

Documentation and requested outcome

The official Computer Use documentation describes the Computer Use plugin and its MCP server. The Locked Use section additionally describes an authorization plugin and trusted active-turn restrictions. I understand that ordinary MCP configuration does not grant this authority.

A useful resolution would be either:

• a documented, version-matched Intel installation/MCP access path; or
• an explicit architecture limitation and actionable UI error, plus clarification of whether a supported native-provider interface exists.

If Intel is intended to be supported, please validate the final distributed artifacts, including the plugin entry, MCP client, native service and required helper dependencies, rather than only the main app or sky.node architecture.

Diagnostic boundaries

No official application binaries were patched, no official marketplace identity or native-surface configuration was forged, and no authorization database changes or Locked Use installer execution were performed. Separate experiments with a self-identified local MCP executor are not evidence that the official tool entry, authorization, cancellation or Locked Use has been integrated. I am not attaching private screenshots, credentials, signing keys or proprietary binaries, and am not making a benchmark claim against the official implementation.

Thank you for clarifying the supported integration boundary and where an actionable fix belongs.

Start by reviewing the plugin's .mcp.json, bin/computer-use-client-launcher, the @oai/sky paths, and the output of codex plugin list --available --json. Done means maintainers have a documented Intel support matrix or limitation, an actionable installation or error path, and a clear statement about any supported native-provider interface.