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.

Start in the built-in codex_rmcp_client, particularly StreamableHttpClientAdapter and EventNotificationTransport, and trace the initialize request to https://mcp.exa.ai/mcp. Reproduce with the provided TOML configuration in Windows Terminal and PowerShell, comparing Codex's direct request with the successful Node, curl, and .NET requests. Done means Exa MCP initializes without the startup warning, or the underlying transport error is exposed clearly.