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

[SSBrouhard]

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

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

[github-actions]

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

• MCP client for computer-use failed to start #22856

Powered by Codex Action

[SSBrouhard]

Adding a debugging update to head off duplicate-flagging:

• Not MCP client for computer-use failed to start #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 Computer Use does not appear in Settings despite plugin and helper existing #21579 / IgorGanapolsky's marketplace-regeneration theory on Codex Desktop macOS: Computer Use always fails with "runtime app is missing" despite valid 1.0.791 runtime install #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]

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]

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]

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]

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]

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:

• Codex.app on macOS fails code signature verification across versions #18523: Codex.app on macOS fails code signature verification across versions
• Codex Desktop 26.429.61741 invalid signature/entitlements; renderer sandbox fails on macOS arm64 #21399: Codex Desktop invalid signature/entitlements on macOS arm64
• Codex Computer Use fails on macOS 26.4.1 with code-signing invalid helper #21846: Codex Computer Use fails with code-signing invalid helper
• Codex Desktop: locked computer use cannot be enabled on macOS Intel due to native component signing errors #24207: Computer Use native component signing errors
• Codex Desktop for macOS repeatedly triggers syspolicyd / trustd CPU and memory runaway #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]

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]

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.