openaiDeveloperDocs MCP intermittently fails during initialized notification

What happened?

The official openaiDeveloperDocs MCP server intermittently fails during Codex startup. Codex continues with MCP startup incomplete, but the OpenAI docs MCP tools are unavailable for that session.

Error

⚠ MCP client for `openaiDeveloperDocs` failed to start: MCP startup failed: handshaking with MCP server failed: Send message error Transport
  [rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<codex_rmcp_client::http_client_adapter::StreamableHttpClientAdapter>>] error: Transport channel closed, when send initialized notification

⚠ MCP startup incomplete (failed: openaiDeveloperDocs)

Config

[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"

Environment

• Codex CLI: 0.128.0
• Platform: macOS 26.4.1 (25E253), arm64
• MCP transport: streamable HTTP
• Server: https://developers.openai.com/mcp

Observations

• This does not look like a local command/config parse failure: the server is configured by URL only, and the failure occurs during MCP handshaking after the transport is already active.
• A plain GET to the endpoint returns 405 quickly, which is expected for an MCP endpoint but shows the host is reachable:

405 0.005636 0.538203 0.538307

• A HEAD request to the same URL timed out after 10s, suggesting the endpoint/edge may not handle non-MCP methods consistently. This is not an MCP handshake reproduction, just a connectivity clue.
• I also saw a similar remote streamable HTTP startup warning for codex_apps in local logs:

failed to force-refresh tools for MCP server 'codex_apps' ... error sending request for url (https://chatgpt.com/backend-api/wham/apps)

Expected behavior

The official openaiDeveloperDocs MCP server should either initialize reliably or surface a retryable/server-side error with enough detail. A transient transport closure during initialized should ideally be retried or reported with actionable diagnostics.

Related

Similar or possibly related previous issues:

• #5208
• #11919