Remote HTTP MCP servers: handshake OK but tools never exposed in desktop conversations (regression in 26.803.61601/81509)

SummaryNewer Codex Desktop builds (26.803.61601/81509) show a version regression when connecting to remote HTTP MCP servers: the handshake succeeds, but the initialization task is cancelled right after startup, so the tool catalog always treats the server as not ready and MCP tools are completely invisible in conversations. This problem does not exist in the older build (26.803.41515), and it reproduces with both direct HTTP transport and a local stdio proxy wrapping the same servers. This points to a connection-lifecycle management bug, unrelated to configuration or network.

Environment

Codex Desktop (Windows, MSIX): 26.803.61601 and 26.803.81509

Engine/command runner: 0.147.0-alpha.6.6

Remote streamable HTTP MCP servers configured in $CODEX_HOME/config.toml (url + custom http_headers)

ExpectedMCP tools (e.g., get_my_sids, asin_sales_trend) appear in the conversation tool list and can be called.

ActualAt every thread start the server start task is cancelled, and every sampling step omits the server's tools:

start_server_task{server_name=<name>}:initialize:serve_inner: task cancelled
...serve finished quit_reason=Cancelled
rmcp::transport::streamable_http_client | transport_worker{name="StreamableHttpClientWorker"}: cancelled
codex_mcp::connection_manager::tool_catalog ... omitting MCP server without an exact ready client server_name=<name>

The MCP handshake itself succeeds (Service initialized as client, tools capability, protocol 2025-06-18), so the failure is in tool-catalog readiness/registration, not auth, transport, or config.

ImpactMCP-based tools are unusable in desktop app conversations until a fixed build ships.