Codex Desktop Computer Use MCP initialize times out, but same client handshakes from Terminal

Open 💬 11 comments Opened May 21, 2026 by SSBrouhard

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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?

Install/enable computer-use@openai-bundled in Codex Desktop.
Confirm codex mcp list shows computer-use enabled.
In a Codex Desktop session, attempt a Computer Use smoke test such as list_apps or get_app_state({ app: "Finder" }).
Observe that the hosted MCP path times out waiting for the initialize response before tools are available.
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

Send an MCP initialize request over stdio.
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.

View original on GitHub ↗

11 Comments

github-actions[bot] contributor · 2 months ago

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

#22856

Powered by Codex Action

SSBrouhard · 2 months ago

Adding a debugging update to head off duplicate-flagging:

Not #22856: RussellBrand's macOS 15 Swift symbol mismatch (_swift_task_addPriorityEscalationHandler) doesn't apply. I'm on macOS 26.3.1 (Darwin 25.5.0); the binary runs cleanly from Terminal, no dyld errors, MCP initialize handshake succeeds in <1s.
Not #21579 / IgorGanapolsky's marketplace-regeneration theory on #22927: my ~/Library/Logs/com.openai.codex/ shows every bundled_plugins_runtime_marketplace_written event with pluginCount=4 pluginNames=["browser","chrome","computer-use","latex"]. There is no bundled_plugin_uninstall_requested pluginId=computer-use@openai-bundled in my logs. Marketplace correctly includes computer-use on every regen.

The failure is specifically: Codex Desktop's MCP host spawns SkyComputerUseClient mcp but never receives the initialize response, while a stdio probe against the exact same binary (same cdhash 2ee0eafd…) from Terminal completes initialize in <1s.

m13v · 2 months ago

the part that breaks down here is usually stdio buffering, not the handshake. from terminal, isatty(stdout) returns true so libc picks line buffering and the init response flushes on newline. from a GUI posix_spawn with pipes, libc goes fully buffered, and a sub-4KB JSON-RPC reply sits in the child's stdout buffer until it fills. the parent's read() waits forever. fix is setvbuf(stdout, NULL, _IOLBF, 0) at client startup, or forkpty in place of pipe on the spawn side. the _RegisterApplication abort earlier is a separate Aqua-session issue, not what's holding initialize.

SSBrouhard · 1 month ago

Update after installing the latest Codex Desktop build:

Codex Desktop: 26.519.41501
Build: 3044
Computer Use plugin cache is still 1.0.793
codex mcp list still shows computer-use enabled
list_apps still fails with: Computer Use could not start because its runtime app is missing.
get_app_state("Finder") still fails with the same message.

So the app update did not resolve the Computer Use runtime failure on this machine.

SSBrouhard · 1 month ago

Additional update: I removed/reinstalled the Computer Use plugin after updating Codex.

Computer Use upgraded from 1.0.793 to 1.0.799
codex mcp list now points at /Users/vesta/.codex-home/plugins/cache/openai-bundled/computer-use/1.0.799
The runtime bundle itself reports CFBundleVersion = 799
I fully quit/reopened Codex after reinstall
list_apps and get_app_state("Finder") still fail with Computer Use could not start because its runtime app is missing.

For comparison, removing/reinstalling the Chrome plugin did fix the Chrome bridge by moving it to the new app-matched plugin path, but the same reinstall/relaunch flow did not fix Computer Use.

SSBrouhard · 1 month ago

Update after installing another Codex Desktop update:

Codex Desktop: 26.519.81530
Build: 3178
Computer Use remains 1.0.799
codex mcp list still shows computer-use enabled and pointing at 1.0.799
list_apps still fails with Computer Use could not start because its runtime app is missing.
get_app_state("Finder") still fails with the same message after repeated attempts.

New local signing/provisioning evidence:

codesign --verify --deep --strict:
invalid signature (code or signature have been modified)
In architecture: arm64

spctl:
internal error in Code Signing subsystem

Recent macOS logs also show:

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

This seems to match the signing/provisioning angle reported in #22927, and appears separate from the older bundled-marketplace regeneration issue.

SSBrouhard · 1 month ago

Update: this appears to have regressed/changed from my original report.

The original issue was about an MCP initialize timeout after signing/Gatekeeper/quarantine checks were clean. I re-tested with a fresh Codex Desktop download and now the failure is earlier: the downloaded DMG/app bundle itself fails signing and Gatekeeper verification before installation.

Current fresh DMG:

Codex Desktop: 26.602.30954
Codex build: 3575
Bundled computer-use: 1.0.809
DMG path locally: redacted
Active Codex home: .codex-home

Before installation, on the mounted DMG:

codesign --verify --verbose=2 "/Volumes/Codex Installer/Codex.app"

returns:

invalid signature (code or signature have been modified)
In architecture: arm64

Gatekeeper also fails on the mounted app:

spctl -a -vv "/Volumes/Codex Installer/Codex.app"

returns:

/Volumes/Codex Installer/Codex.app: internal error in Code Signing subsystem

The nested Computer Use app inside the mounted DMG also fails:

codesign --verify --deep --strict --verbose=2 "/Volumes/Codex Installer/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app"

with the same invalid signature error.

Gatekeeper on the nested Computer Use app:

spctl -a -vv "/Volumes/Codex Installer/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app"

returns:

/Volumes/Codex Installer/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app: internal error in Code Signing subsystem

After copying to /Applications, /Applications/Codex.app fails the same way. So the copy/install step does not appear to be causing the signing problem.

This is different from my original report where signing checks were clean and the visible failure was MCP initialize timeout. Current state looks like a signing/Gatekeeper verification problem present in the distributed DMG/app bundle before local installation.

Closest related issues I found:

#18523: Codex.app on macOS fails code signature verification across versions
#21399: Codex Desktop invalid signature/entitlements on macOS arm64
#21846: Codex Computer Use fails with code-signing invalid helper
#24207: Computer Use native component signing errors
#25719: syspolicyd/trustd issues around Codex Computer Use

I did not find another issue specifically confirming this on a freshly mounted 26.602.30954 DMG before installation, with both Codex.app and bundled computer-use 1.0.809 failing codesign/spctl.

SSBrouhard · 1 month ago

Can someone else on macOS arm64 test the mounted 26.602.30954 DMG before installation with:

codesign --verify --verbose=2 "/Volumes/Codex Installer/Codex.app"
spctl -a -vv "/Volumes/Codex Installer/Codex.app"

On my machine, codesign returns:

invalid signature (code or signature have been modified)
In architecture: arm64

and spctl returns:

/Volumes/Codex Installer/Codex.app: internal error in Code Signing subsystem

I’m trying to determine whether this is a distributed signing issue or local trust subsystem state on my Mac.

SSBrouhard · 1 month ago

Update after clean reinstall:

A targeted clean reinstall did not fix this.

I quit Codex, backed up ~/.codex-home, removed /Applications/Codex.app, and removed:

~/.codex-home/computer-use
~/.codex-home/plugins/cache/openai-bundled/computer-use

Then I installed the latest Codex app fresh.

After relaunch:

Computer Use cache was recreated as computer-use/1.0.809
Runtime app exists at ~/.codex-home/computer-use/Codex Computer Use.app
SkyComputerUseService is running
Cache and runtime both pass codesign verification
SkyComputerUseClient can initialize over MCP and list tools
Runtime-dependent tool calls such as list_apps/get_app_state still return:

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

Fresh macOS logs still show:

“Entitlement com.apple.security.application-groups ... is ignored because of invalid application signature or incorrect provisioning profile.”

The signed app entitlement requests app group:

2DC432GLL2.com.openai.sky.CUAService

But the embedded provisioning profile lists app groups including:

group.com.openai.sky.CUAService
2DC432GLL2.*

So this no longer looks like stale cache or a locally broken install. The runtime exists and launches, but the Computer Use 1.0.809 client/service handoff appears unable to bind through the expected App Group/sandbox channel on this machine.

SSBrouhard · 13 days ago

Update July 8, 2026:

This still reproduces after a clean Codex reinstall with computer-use@openai-bundled 1.0.857.

Current observations:

/Applications/Codex.app was deleted and freshly reinstalled.
Targeted Computer Use state was reset:
~/.codex-home/plugins/cache/openai-bundled/computer-use
~/.codex-home/computer-use
Codex relaunches cleanly.
Computer Use plugin tools are discoverable.
SkyComputerUseService is running.
SkyComputerUseClient mcp processes are running.
The runtime app exists on disk.
Code signatures and entitlements look valid.
App group container and IPC socket exist.
No useful crash report is emitted.

But calls still fail. The repeated smoke tests return either:

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

or, after restarting the helper processes:

tool call failed for `computer-use/list_apps`

Caused by:
    Transport closed

So this still looks like a Codex Desktop hosted MCP/client-service handshake failure, not a missing runtime app, broken signature, stale plugin cache, or macOS permissions issue.

SSBrouhard · 13 days ago

Follow-up on the 1.0.857 repro:

I tested the related workaround from #28479 by adding explicit env vars to the Computer Use MCP manifest:

"env": {
  "CODEX_HOME": "/Users/vesta/.codex-home",
  "CODEX_SQLITE_HOME": "/Users/vesta/.codex-home/sqlite"
}

After fully relaunching Codex, the live SkyComputerUseClient mcp processes do now inherit both variables:

CODEX_HOME=/Users/vesta/.codex-home
CODEX_SQLITE_HOME=/Users/vesta/.codex-home/sqlite

I also checked LaunchServices/runtime discovery. open -b com.openai.sky.CUAService launches the live service at:

/Users/vesta/.codex-home/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

So the current failure is not explained by missing CODEX_HOME / CODEX_SQLITE_HOME, and LaunchServices can resolve the live service bundle.

Despite that, list_apps still fails. Current observed error after the env fix is:

tool call failed for `computer-use/list_apps`

Caused by:
    Transport closed