codex cli 0.149.1 fails to connect to exa MCP, because built-in `codex_rmcp_client` failing to make a direct HTTPS connection to Exa.

What version of Codex CLI is running?

0.149.1

What subscription do you have?

plus

Which model were you using?

gpt-5.6-terra max

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal + pwsh (PowerShell 7.6.3)

Codex doctor report

What issue are you seeing?

⚠ MCP client for exa failed to start: MCP startup failed: handshaking with MCP server failed: Send
message error Transport
[codex_rmcp_client::event_notification_transport::EventNotificationTransport<rmcp::transport::worker::W
orkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<codex_rmcp_client::h
ttp_client_adapter::StreamableHttpClientAdapter>>>] error: Client error: HTTP request failed:
http/request failed: error sending request for url (https://mcp.exa.ai/mcp), when send initialize
request

⚠ MCP startup incomplete (failed: exa)

What steps can reproduce the bug?

just run codex in pwsh with the following config:

[mcp_servers.exa]
url = "https://mcp.exa.ai/mcp"

What is the expected behavior?

_No response_

Additional information

codex cli 0.149.1 fails to connect to exa MCP.

I tried having the AI analyze the issue on its own in codex cli. The conclusion is as follows:

The root cause has been narrowed down to Codex 0.149.1's built-in codex_rmcp_client failing to make a direct HTTPS connection to Exa, rather than an Exa, authentication, or MCP configuration error.
Evidence:

• In the real valid configuration, Exa has no auth header, yet it still fails on send initialize request.
• A standard MCP POST initialize sent from Node on the same machine to the same URL returns 200.
• Windows curl and .NET HttpClient with HTTP/1.1 and HTTP/2 forced both successfully return 200.
• I used a local transparent proxy to capture Codex's actual request, then forwarded it to Exa via Node. Exa successfully completed initialize, notifications/initialized, and tools/list; Codex then started normally with no Exa warnings.
• Therefore, the MCP message format sent by Codex is correct; the failure only occurs in its internal HTTP transport for the direct connection to https://mcp.exa.ai/mcp. The logs for that version wrap and lose the lower-level TLS/connection error, so it cannot be further located from the configuration layer.

Therefore:

[mcp_servers.exa]
url = "https://mcp.exa.ai/mcp"

is already the correct configuration; EXA_API_KEY, http_headers, env_http_headers, and startup_timeout_sec cannot fix this direct-connection transport error. The timeout configuration is especially ineffective because it fails immediately when the first request is sent, and Codex has already automatically retried three times.