codex - 💡(How to fix) Fix Codex Desktop Computer Use MCP initialize times out, but same client handshakes from Terminal

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Codex Desktop should be able to spawn the bundled Computer Use MCP client and receive its initialize response the same way direct Terminal invocation does. After initialize, list_apps and get_app_state should be available and should either return app state or a specific actionable runtime error.

Root Cause

  • list_apps and get_app_state("Finder") returned isError:true with "Computer Use could not start because its runtime app is missing."
  • Telemetry included did_trigger_server_user_flow:false.

Code Example

cd ~/.codex-home/plugins/cache/openai-bundled/computer-use/1.0.793
./Codex\ Computer\ Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp
RAW_BUFFERClick to expand / collapse

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.513.31313; computer-use@openai-bundled 1.0.793

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Computer Use has moved past the earlier "runtime app is missing" failure, but now Codex Desktop appears unable to complete the MCP initialize handshake with the same bundled client binary that works from Terminal.

Current behavior:

  • In Codex Desktop, a clean Computer Use MCP smoke test fails before tools are available: the MCP client starts but no initialize response is received, so list_apps and get_app_state cannot be called.
  • Direct invocation from Terminal of the same SkyComputerUseClient mcp binary responds to MCP initialize in under 1 second with a clean handshake.
  • This makes it look like the bundled client/runtime is healthy, but the Codex Desktop MCP host/spawn environment cannot receive or handle the initialize response.

Earlier phase, before plugin/cache/runtime cleanup:

  • list_apps and get_app_state("Finder") returned isError:true with "Computer Use could not start because its runtime app is missing."
  • Telemetry included did_trigger_server_user_flow:false.

After cleanup/fresh plugin/runtime:

  • LaunchServices resolves correctly.
  • Plugin cache is fresh.
  • Signatures/Gatekeeper/quarantine checks are clean.
  • No crash report in the current initialize-timeout phase.
  • The client starts, but Codex Desktop does not get an initialize response.

This appears related to #22856 and follows the earlier symptom in #22927, but the important difference is that direct Terminal MCP initialize succeeds here. So this does not look like the macOS Swift runtime mismatch/direct client crash cases.

What steps can reproduce the bug?

  1. Install/enable computer-use@openai-bundled in Codex Desktop.
  2. Confirm codex mcp list shows computer-use enabled.
  3. In a Codex Desktop session, attempt a Computer Use smoke test such as list_apps or get_app_state({ app: "Finder" }).
  4. Observe that the hosted MCP path times out waiting for the initialize response before tools are available.
  5. From Terminal, run the same bundled client binary directly:
cd ~/.codex-home/plugins/cache/openai-bundled/computer-use/1.0.793
./Codex\ Computer\ Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp
  1. Send an MCP initialize request over stdio.
  2. Observe that the same binary responds in under 1 second with a clean MCP handshake.

What is the expected behavior?

Codex Desktop should be able to spawn the bundled Computer Use MCP client and receive its initialize response the same way direct Terminal invocation does. After initialize, list_apps and get_app_state should be available and should either return app state or a specific actionable runtime error.

Additional information

Environment:

  • macOS: 26.3.1 (25D771280a) per previous system report; current uname -mprs: Darwin 25.5.0 arm64 arm
  • Codex Desktop: 26.513.31313
  • Computer Use plugin: 1.0.793
  • Binary: SkyComputerUseClient
  • Reported client cdhash from local check: 2ee0eafd...
  • Backups preserved at ~/.codex-backups/

Ruled out locally:

  • Missing helper binary
  • Stale plugin cache after refresh
  • Signing/notarization/Gatekeeper/quarantine
  • LaunchServices misdirection after cleanup
  • Direct client crash on Terminal invocation

Potential related context: earlier attempts had a crash trace around NSApplication init -> _RegisterApplication -> abort() when a helper was spawned in an environment without a proper Aqua session. That may be related to the Desktop spawn/session environment, but the current visible failure is an initialize timeout, not a crash.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING