Codex Desktop macOS: Computer Use always fails with "runtime app is missing" despite valid 1.0.791 runtime install

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

• #21579

Powered by Codex Action

@Scubasteve417 — the runtime app is missing error here looks like the same downstream symptom as #21579, where @ShalevZorany dug into the Codex Desktop logs and found a concrete root cause that's worth checking before chasing reinstall paths:

On every Codex Desktop launch, the BundledPluginsMarketplace regenerates the runtime bundled marketplace with only browser and latex, and then explicitly uninstalls chrome and computer-use with reason=not_in_bundled_marketplace_plugin_names. Once that happens, the helper bundle still exists on disk but the runtime can't reach it — which surfaces exactly as Computer Use could not start because its runtime app is missing from list_apps / get_app_state, even after a clean reinstall.

Quickest way to confirm you're hitting the same bug — grep your Codex Desktop logs for these strings right after a relaunch:

bundled_plugins_runtime_marketplace_written pluginCount=2 pluginNames=["browser","latex"]
bundled_plugin_uninstall_requested pluginId=computer-use@openai-bundled

If both lines appear on every startup, your cache, codesign, LaunchServices state, and Chrome native-host manifest are not the gap — Codex Desktop itself is regenerating the bundled marketplace without computer-use and removing it. In that case reinstalling the runtime can't help (Codex removes it again on next launch); the workaround until OpenAI ships a fix is to restore the marketplace from /Applications/Codex.app/Contents/Resources/plugins/openai-bundled after each launch, which is what @ShalevZorany ended up doing in #21579.

If those log lines don't appear, then it's not the marketplace-regeneration bug and the diagnostic forks are different — happy to dig in.

(Longer write-up of the runtime-vs-cache-vs-marketplace distinctions for this error: https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/computer-use-plugin-unavailable.html)

I’m seeing the same Computer Use failure on macOS:

"Computer Use could not start because its runtime app is missing."

Important distinction: this appears isolated to the desktop Computer Use runtime. In another session, the Chrome plugin path worked through the Codex Chrome Extension/native host using the browser client:

• setupBrowserRuntime({ globals: globalThis })
• agent.browsers.get("extension")
• browser.user.openTabs()
• browser.user.claimTab(...)

So Computer Use is blocked, but Chrome extension-backed automation can still be usable when routed through the Chrome plugin browser bridge.

I am seeing the same Computer Use could not start because its runtime app is missing failure on macOS, but my local diagnostics look slightly different from the marketplace-regeneration case discussed above.

Environment:

• macOS 26.3, build 25D125, arm64
• Codex Desktop 26.519.41501, build 3044
• bundled codex-cli 0.133.0-alpha.1
• computer-use@openai-bundled 1.0.799

Symptoms:

• computer-use/list_apps fails repeatedly with:

Computer Use could not start because its runtime app is missing

• codex mcp list shows computer-use as enabled.
• The Computer Use helper app exists on disk.
• codesign --verify --deep --strict passes for:

$CODEX_HOME/plugins/cache/openai-bundled/computer-use/1.0.799/Codex Computer Use.app

This does not appear to be the reduced bundled marketplace case. My Codex Desktop logs repeatedly show all four bundled plugins:

[BundledPluginsMarketplace] bundled_plugins_runtime_marketplace_written pluginCount=4 pluginNames=["browser","chrome","computer-use","latex"]

I also do not see bundled_plugin_uninstall_requested pluginId=computer-use@openai-bundled.

One suspicious detail from macOS system logs: the Computer Use service/client appears to start, but macOS logs repeated entitlement/provisioning warnings for com.openai.sky.CUAService:

taskgated-helper: Disallowing com.openai.sky.CUAService because no eligible provisioning profiles found
trustd: Entitlement com.apple.security.application-groups=("2DC432GLL2.com.openai.sky.CUAService") is ignored because of invalid application signature or incorrect provisioning profile

So this may be a separate runtime helper signing/provisioning/entitlement issue rather than the bundled marketplace being generated with only browser and latex.

Happy to provide more sanitized logs if useful.

I am seeing the same visible failure on macOS, but with a more recent Codex/Desktop and computer-use@openai-bundled 1.0.809. The current local evidence points away from Gatekeeper/signing/permissions as the primary cause and toward the Computer Use client -> short-lived app-server -> runtime discovery path.

Environment:

• macOS: Darwin 25.5.0 arm64, macOS 26.x
• Codex Desktop: 26.609.30741, bundle version 3808
• Bundled CLI: /Applications/Codex.app/Contents/Resources/codex --version -> codex-cli 0.140.0-alpha.2
• Computer Use plugin/runtime: 1.0.809
• Runtime app path: ~/.config/codex/computer-use/Codex Computer Use.app
• Bundled plugin path: ~/.config/codex/plugins/cache/openai-bundled/computer-use/1.0.809

Visible failure:

SkyComputerUseClient mcp
initialize -> success
tools/list -> success
tools/call list_apps -> isError=true
text="Computer Use could not start because its runtime app is missing. Try again, and if it fails after 2 more tries, suggest that the user relaunch Codex."

Important distinction: tools/list succeeds and returns the Computer Use tool schemas. The failure first appears when executing list_apps. So the MCP stdio server can start, parse JSON-RPC, and advertise tools; the failing path is the actual Computer Use session/runtime startup path.

I also reran the manual MCP repro using Codex's bundled OpenAI-signed Node instead of my shell's Node, to avoid parent-process signing pollution:

cd ~/.config/codex/plugins/cache/openai-bundled/computer-use/1.0.809

/Applications/Codex.app/Contents/Resources/cua_node/bin/node -e 'const {spawn}=require("child_process");
const bin="./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient";
const p=spawn(bin,["mcp"],{cwd:process.cwd(),stdio:["pipe","pipe","pipe"]});
p.stdout.on("data",d=>process.stdout.write("STDOUT "+d));
p.stderr.on("data",d=>process.stderr.write("STDERR "+d));
p.on("exit",(code,signal)=>console.log("EXIT",code,signal));
function send(o){const s=JSON.stringify(o); console.log("SEND",s); p.stdin.write(s+"\n");}
send({jsonrpc:"2.0",id:1,method:"initialize",params:{protocolVersion:"2024-11-05",capabilities:{},clientInfo:{name:"manual-debug-openai-node",version:"0.1"}}});
setTimeout(()=>send({jsonrpc:"2.0",method:"notifications/initialized",params:{}}),200);
setTimeout(()=>send({jsonrpc:"2.0",id:2,method:"tools/list",params:{}}),450);
setTimeout(()=>send({jsonrpc:"2.0",id:3,method:"tools/call",params:{name:"list_apps",arguments:{}}}),900);
setTimeout(()=>{console.log("TIMEOUT_KILL"); p.kill("SIGTERM");},8500);'

The result is still:

initialize -> success
tools/list -> success
tools/call list_apps -> runtime app is missing

Signing / Gatekeeper checks from the host environment pass:

codesign --verify --deep --strict --verbose=2 /Applications/Codex.app
-> valid on disk
-> satisfies its Designated Requirement

codesign --verify --deep --strict --verbose=2 ~/.config/codex/computer-use/Codex\ Computer\ Use.app
-> valid on disk
-> satisfies its Designated Requirement

codesign --verify --deep --strict --verbose=2 ~/.config/codex/plugins/cache/openai-bundled/computer-use/1.0.809/Codex\ Computer\ Use.app
-> valid on disk
-> satisfies its Designated Requirement

spctl -a -vv -t execute ~/.config/codex/computer-use/Codex\ Computer\ Use.app
-> accepted
-> source=Notarized Developer ID
-> origin=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

spctl -a -vv -t execute ~/.config/codex/plugins/cache/openai-bundled/computer-use/1.0.809/Codex\ Computer\ Use.app
-> accepted
-> source=Notarized Developer ID
-> origin=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

Entitlements are readable and include the expected app group:

<key>com.apple.application-identifier</key>
<string>2DC432GLL2.com.openai.sky.CUAService</string>
<key>com.apple.security.application-groups</key>
<array>
  <string>2DC432GLL2.com.openai.sky.CUAService</string>
</array>

and for the client:

<key>com.apple.application-identifier</key>
<string>2DC432GLL2.com.openai.sky.CUAService.cli</string>
<key>com.apple.security.application-groups</key>
<array>
  <string>2DC432GLL2.com.openai.sky.CUAService</string>
</array>

The runtime app is present and LaunchServices can start it:

open -g -b com.openai.sky.CUAService

This starts:

~/.config/codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

Pre-starting the service does not make list_apps succeed.

TCC/accessibility evidence from unified logs shows allow for ListenEvent on both client and service:

process=SkyComputerUseClient
service=kTCCServiceListenEvent
auth_value=2
result=true

process=SkyComputerUseService
service=kTCCServiceListenEvent
auth_value=2
result=true

I could not directly query TCC.db because macOS denied read access, so I am treating unified logs as the evidence source here.

Most suspicious local evidence:

1. The plugin .mcp.json directly execs the Mach-O inside the app bundle:

{
  "mcpServers": {
    "computer-use": {
      "command": "./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient",
      "args": ["mcp"],
      "cwd": "."
    }
  }
}

1. When launched this way, macOS records the client as not LaunchServices-launched:

SkyComputerUseClient
BringForward ... launchedByLS=0
Identity resolved as anon<SkyComputerUseClient>(501)

LaunchServices also logs on exit:

DEATH: Received pid death for ... SkyComputerUseClient ... which was not a LS launched process

1. Launching the same SkyComputerUseClient.app through LaunchServices gives a normal app identity:

open -g -a "$HOME/.config/codex/plugins/cache/openai-bundled/computer-use/1.0.809/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app" --args --help

Unified log then shows:

LSLaunchedByLaunchServices=true
app<application.com.openai.sky.CUAService.cli...>

1. During list_apps, the client starts a short-lived app-server:

SkyComputerUseClient: Launching codex app-server with executable /Applications/Codex.app/Contents/Resources/codex
codex[short-lived pid]: starts

But in that call window I do not see SkyComputerUseService being launched or participating in the call. The user-visible error is returned immediately after this path.

1. SkyComputerUseClient_Parent.coderequirement only contains:

<key>team-identifier</key>
<string>2DC432GLL2</string>

Using my shell Node did not satisfy this, but using Codex's bundled Node does satisfy it and still reproduces the same failure. So parent-process signing is a real variable for clean repros, but not sufficient to explain this machine's failure.

1. Strings in the Computer Use binaries show separate error branches for permissions, version mismatch, and service-app discovery:

Computer Use permissions are still pending
Computer Use permissions are not granted
The Computer Use server and client have a version mismatch...
Computer Use could not start because its runtime app is missing...
couldNotFindServiceApp
codex app-server exited before returning auth status
codex app-server returned an invalid response
codex app-server rejected ...

The actual returned message matches the service-app discovery branch, not the permissions-pending/not-granted branch and not the version-mismatch branch.

1. There is no managed app-server daemon control socket on this machine:

codex app-server daemon version
-> failed to connect to ~/.config/codex/app-server-control/app-server-control.sock
-> No such file or directory

Codex Desktop's main app-server is running, but Computer Use still starts a short-lived stdio app-server during list_apps.

Current interpretation:

The visible runtime app is missing message is misleading on this setup. The runtime app exists, passes host-side signing/Gatekeeper checks, can be started by LaunchServices, and can obtain at least the accessibility/event-tap TCC permission seen in logs. The failure appears to be in the direct-exec MCP client path when list_apps triggers the client -> short-lived codex app-server -> com.openai.sky.CUAService discovery/start/auth path. That short-lived path is not successfully discovering or starting the installed runtime service.

This looks related to this issue's symptom, but it is not the older reduced bundled-marketplace case and does not currently look like the previously observed sandbox-only codesign false negative either.

For what it's worth, this now seems to be working for me after updating Codex.

My guess is that it may have been related to the recent Computer Use / plugin availability rollout in Europe, which now appears to be available. I am actually based in Israel, so the regional behavior was a bit confusing, but after updating Codex the feature is visible and working on my machine.

It may be worth checking again after updating to the latest Codex build.

After update to the latest Codex, this bug is fixed.

I can reproduce this on Codex Desktop 26.623.81905, CLI 0.142.5, computer-use@openai-bundled 1.0.857, macOS 27.0 build 26A5368g.

This is not the #21579 marketplace regeneration case: logs show pluginCount=5 including computer-use.

Manual MCP initialize/tools-list works, but tools/call list_apps returns runtime app is missing. Codex Computer Use.app is running according to lsappinfo, launchctl has application.com.openai.sky.CUAService, and the IPC socket exists under ~/Library/Group Containers/2DC432GLL2.com.openai.sky.CUAService/IPC/computeruse.sock.

Crash reports show SkyComputerUseService/SkyComputerUseClient aborting with SIGABRT around _RegisterApplication / NSApplication on macOS 27.0.