Codex Desktop local stdio MCP fails initialize while the same config works in Codex CLI

Summary

Codex Desktop can read a project-level stdio MCP configuration and show the server in its MCP UI, but the server never becomes usable. The same server, configuration semantics, and consumer project complete MCP initialization and expose all tools in both the official MCP SDK and Codex CLI.

The failure is specific to the Desktop host integration observed here: the Desktop process disconnects while waiting for the MCP initialize response. The exact Desktop-side root cause is not yet known.

Environment

• OS: macOS on Apple silicon
• Codex CLI: 0.154.0
• Codex Desktop doctor version: 26.908.40834
• MCP configuration: project-level .codex/config.toml
• MCP server name: openapi_to
• Transport: local stdio
• Consumer root: <PROJECT_ROOT>

The relevant configuration is:

[mcp_servers.openapi_to]
command = "pnpm"
args = [
  "exec",
  "--",
  "openapi-to-mcp",
  "--workspace-root",
  ".",
  "--config",
  "openapi.config.ts"
]
cwd = "."
startup_timeout_sec = 10
tool_timeout_sec = 60

Reproduction

1. In a consumer project root, configure the local stdio server as shown above.
2. Start Codex Desktop with that project open.
3. Observe the openapi_to server in the Desktop MCP UI.
4. Inspect the Desktop MCP startup state and available tools.

The same consumer root and arguments were also used for the control tests described below.

Actual behavior

Desktop reads the project-level MCP configuration and displays the server, but no openapi_* tools are available.

The Desktop logs repeatedly report:

status=starting
MCP startup failed:
handshaking with MCP server failed:
connection closed:
initialize response:
connection closed

This failure was observed 18 times. The Desktop-side diagnostics do not currently show the child exit code, child stderr, effective child cwd, child environment, or an initialize wire trace.

Expected behavior

With the same project-level stdio MCP configuration, Codex Desktop should complete initialize and expose the same 8 tools as Codex CLI.

If the child process fails, Desktop should at minimum provide bounded and sanitized child stderr, exit code, effective cwd, or another startup failure reason sufficient to distinguish an MCP server failure from a Desktop host-integration failure.

Control tests / evidence

Client or test	Result	Evidence
Official MCP SDK StdioClientTransport	PASS	Using the consumer root as cwd and --workspace-root . --config openapi.config.ts, initialize and tools/list succeed with 8 tools. A real openapi_list_targets call also succeeds and finds swr-api.
Same launcher through pnpm	PASS	Starting with pnpm exec -- openapi-to-mcp ... and using the official SDK produces the same successful initialize and 8-tool tools/list result; openapi_list_targets also succeeds.
Codex CLI 0.154.0	PASS	From the same consumer root, /mcp reports openapi_to: connected (8 tools).
Codex Desktop 26.908.40834	FAIL	The server appears in the MCP UI, but the initialize-response connection closes and no openapi_* tools are available.

The CLI startup also reported an unrelated morph-mcp failure. That is separate from openapi_to and is not part of this report.

Desktop log evidence

Minimal sanitized excerpt:

MCP startup failed:
handshaking with MCP server failed:
connection closed:
initialize response:
connection closed

No complete Desktop log, account data, thread IDs, session IDs, credentials, or environment dump is included.

What has been ruled out

The successful controls rule out, for this reproduction:

• an MCP server runtime failure;
• the pnpm exec wrapper itself;
• ordinary Terminal PATH or command-resolution failure;
• failure to load openapi.config.ts;
• failure of the Desktop app-server handshake;
• failure of Desktop config loading or MCP config parsing.

A negative cwd control was also performed. Running the same server arguments with cwd=/tmp through the direct SDK still completes initialize and tools/list with 8 tools; only the later openapi_list_targets call fails because the project configuration cannot be loaded from that cwd. Therefore the relative cwd = "." has portability risk, but it does not explain the observed initialize-response disconnect.

Remaining unknowns

The current evidence does not identify:

• whether the Desktop child exits, and if so with which exit code;
• what stderr the Desktop child produced;
• the effective child cwd or environment;
• the exact initialize wire exchange seen by Desktop;
• whether the cause is environment forwarding, process lifecycle, sandboxing, framing, or another Desktop-side integration issue.

The confirmed conclusion is:

Same local stdio MCP and configuration work in the official SDK and Codex CLI, while Codex Desktop fails during initialize-response. The exact Desktop-side root cause is not yet known.

Related issues

• #6020 is a generic MCP initialize-response failure report from an older context; it does not provide this current Desktop-vs-CLI control.
• #42079 covers Desktop startup-failure reporting and silent omission of failed plugin tools; this report adds a reproducible failure at the initialize-response boundary with CLI and SDK controls.
• #38162 completes Desktop initialize and tools/list successfully but fails to expose the discovered tools; this report fails earlier while waiting for the initialize response.
• #45379 concerns a Windows local-plugin handshake failure that causes a Desktop restart loop; this report is on macOS and does not establish a restart loop.
• #15365 reports a macOS Browser MCP tool-call transport failure while CLI succeeds; this report concerns a generic local stdio server disconnecting during initialization.

All paths and identifiers in this report are sanitized. No username, absolute home or project path, token, credential, complete environment, private session identifier, or unreviewed full log is included.

No source files, tests, or implementation entry points are identified. Reproduce with the project-level .codex/config.toml and compare Codex Desktop startup against the successful SDK and CLI controls, focusing on the initialize-response disconnect and available diagnostics. Done means Desktop exposes the same 8 tools, or reports enough sanitized child failure details to distinguish the failure boundary.