Codex Desktop Computer Use can fail when SkyComputerUseClient lacks CODEX_HOME/CODEX_SQLITE_HOME

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

Codex Desktop 26.609.71450

Additional local versions:

codex-cli 0.140.0-alpha.2
Bundled Computer Use plugin cache: computer-use@openai-bundled 1.0.809
Bundled Computer Use service bundle: com.openai.sky.CUAService, version 1.0 / bundle version 809
Platform: Darwin 25.3.0 arm64 arm

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Computer Use can fail in a current Codex Desktop thread with either:

Transport closed

or:

codex app-server exited before returning a response

In the successful recovery case I investigated, the decisive problem was not a missing Computer Use plugin, not a missing runtime app, and not an app-server stdio/auth failure. The failure was that the Desktop-spawned Computer Use MCP process (SkyComputerUseClient mcp) did not inherit the runtime environment needed by the app-server bridge.

Specifically, the live SkyComputerUseClient mcp process was missing:

CODEX_HOME
CODEX_SQLITE_HOME

After adding those keys explicitly to the Computer Use .mcp.json, restarting only the Codex app-server child process, rerunning deferred plugin discovery with tool_search, and retrying mcp__computer_use.list_apps in the same thread, Computer Use recovered and returned real app output.

This is confusing for users and agents because the initial symptoms look like a stale thread, broken plugin cache, signing/runtime failure, or generic app-server failure. The missing MCP env path should be diagnosed and remediated explicitly.

What steps can reproduce the bug?

This was observed after repeated Computer Use failures in a Codex Desktop thread.

1. In Codex Desktop on macOS, use the bundled Computer Use plugin.
2. Trigger Computer Use discovery with tool_search.
3. Try a read-only Computer Use call such as:

mcp__computer_use.list_apps

1. Observe either Transport closed or codex app-server exited before returning a response.
2. Verify that the app-server bridge itself is not the immediate blocker:

/Applications/Codex.app/Contents/Resources/codex app-server --stdio

Then send initialize, initialized, and getAuthStatus; this path can succeed.

1. Inspect the live Computer Use MCP process environment:

ps eww -p <SkyComputerUseClient-mcp-pid>

In the failing case, CODEX_HOME and CODEX_SQLITE_HOME were absent.

1. Back up the relevant ~/.codex files, then add explicit env keys to the Computer Use .mcp.json, for example:

{
  "mcpServers": {
    "computer-use": {
      "command": "./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient",
      "args": ["mcp"],
      "cwd": "/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/1.0.809/.",
      "env": {
        "CODEX_HOME": "/Users/<user>/.codex",
        "CODEX_SQLITE_HOME": "/Users/<user>/.codex/sqlite"
      }
    }
  }
}

1. Restart the Codex app-server child process so the MCP manager reloads the manifest.
2. In the same thread, rerun tool_search.
3. Retry:

mcp__computer_use.list_apps

Actual recovery proof from the local diagnostic surface after repair:

computer_use.mcp.env = CODEX_HOME=*****, CODEX_SQLITE_HOME=*****
computer_use.mcp_manifest.env_keys = CODEX_HOME,CODEX_SQLITE_HOME
computer_use.mcp_manifest.missing_required_env = []
computer_use.processes.client_running = true
computer_use.processes.service_running = true

The same diagnostic path also confirmed that the remediation for the failed state must include CODEX_HOME, .mcp.json, app-server child restart, tool_search, and list_apps.

What is the expected behavior?

Codex Desktop should either:

1. Ensure bundled Computer Use MCP processes always receive the required runtime env (CODEX_HOME and CODEX_SQLITE_HOME) when spawned by the app-server/MCP manager, or
2. Detect the missing env and report a specific actionable error instead of surfacing generic Transport closed or codex app-server exited before returning a response.

The in-thread repair path should also be reflected in troubleshooting guidance: before telling users to restart Desktop or switch threads, verify app-server stdio health, inspect the live SkyComputerUseClient mcp env, restart the app-server child after manifest repair, rerun tool_search, and prove recovery with list_apps.

Additional information

Related but not identical issues:

• #23840 reports that Codex Desktop Computer Use MCP initialize times out while the same client handshakes from Terminal.
• #28250 reports list_apps / get_app_state failing with app-server exited, with evidence pointing to helper entitlement/provisioning problems.
• #18555 involves CODEX_HOME path parsing when it contains @.

This issue is narrower: the observed root cause was missing CODEX_HOME / CODEX_SQLITE_HOME in the Desktop-spawned SkyComputerUseClient mcp environment. The same thread recovered after adding those env keys to the Computer Use MCP manifest and restarting the app-server child.

No raw session logs are attached here. The above is a distilled, sanitized failure taxonomy and recovery path from local investigation.