Intermittent MCP startup failure for official openaiDeveloperDocs streamable HTTP server
What version of Codex is running?
codex-cli 0.128.0
~/.codex/version.json:
{"latest_version":"0.128.0","last_checked_at":"2026-05-07T12:20:00.615641Z","dismissed_version":null}
Which model were you using?
GPT-5.5 from a Codex session.
What platform is your computer?
macOS 26.4.1 (25E253), arm64.
What steps can reproduce the bug?
- Configure the official OpenAI Developer Docs MCP server in
~/.codex/config.toml:
[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"
- Start Codex.
- Observe MCP startup. The failure is intermittent rather than 100% reproducible.
What is the expected behavior?
The official openaiDeveloperDocs MCP server should complete startup/handshake successfully, or the client should retry/recover cleanly when the streamable HTTP transport is closed during startup.
What do you see instead?
Codex reports that the MCP startup is incomplete:
⚠ 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)
Local observations
The local config is just the URL above, so this does not appear to be a local command startup failure or missing binary. It looks like the built-in streamable HTTP MCP client is able to reach the remote endpoint but the transport closes during the MCP initialization sequence.
A plain probe confirms the endpoint exists but is not a normal GET endpoint:
curl -sS --max-time 10 -o /dev/null -w '%{http_code} %{content_type} %{time_connect} %{time_starttransfer} %{time_total}\n' https://developers.openai.com/mcp
405 0.005636 0.538203 0.538307
A plain curl -I --max-time 10 https://developers.openai.com/mcp timed out with no bytes received, which may or may not be relevant because this is not a valid MCP handshake.
Related issues
This looks similar to prior streamable HTTP MCP transport failures, but the affected server here is the official OpenAI Developer Docs MCP endpoint:
- #5208
- #11919
Additional information
The failure is especially confusing because the warning makes startup look partially broken even though the main Codex session can continue. If this is expected to happen due to transient remote service/network behavior, it would still help if Codex retried the official docs MCP or surfaced a clearer explanation.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗