codex_apps MCP startup fails on wham/apps even when proxied endpoint is reachable

Summary

codex_apps MCP startup fails on chatgpt.com/backend-api/wham/apps even when the endpoint is reachable through the configured proxy path and core Codex requests work.

This does not look like a simple HTTP_PROXY / HTTPS_PROXY / WS_PROXY / WSS_PROXY env omission. The proxied endpoint is reachable, but the RMCP streamable HTTP handshake fails during initialize / initialized notification exchange.

Environment

• Codex CLI: v0.118.0
• Auth: ChatGPT OAuth (~/.codex/auth.json)
• Linux host
• Proxy env set:
• HTTP_PROXY=http://127.0.0.1:10809
• HTTPS_PROXY=http://127.0.0.1:10809
• WS_PROXY=http://127.0.0.1:10809
• WSS_PROXY=http://127.0.0.1:10809
• ALL_PROXY=socks5h://127.0.0.1:10808
• NO_PROXY=127.0.0.1,localhost,...

Repro

1. Use ChatGPT OAuth auth.
2. Ensure apps = true (default behavior is enough; explicit config also reproduces):

[features]
apps = true

1. Run:

codex e ping --skip-git-repo-check

Actual result

Startup shows:

⚠ MCP client for `codex_apps` 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::rmcp_client::StreamableHttpResponseClient>>] error: Transport channel closed, when send initialized notification

And the runtime log contains:

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

Important observation

The same proxy path can reach the wham/apps endpoint successfully outside Codex.

Using the same auth token and the same HTTP proxy:

curl --proxy http://127.0.0.1:10809 \
  -H "Authorization: Bearer <access_token>" \
  -H "Accept: application/json" \
  -D - \
  https://chatgpt.com/backend-api/wham/apps

Response:

HTTP/2 405
allow: POST
content-type: application/json
{"detail":"Method Not Allowed"}

So the endpoint is reachable through the configured proxy path, and the failure appears to be in the RMCP / streamable HTTP handshake path rather than simple proxy env pickup.

Workaround

Disable apps/connectors:

[features]
apps = false

With that, the codex_apps startup warning disappears.

Relevant code paths

• codex-rs/core/src/mcp/mod.rs
• codex-rs/rmcp-client/src/rmcp_client.rs
• build_http_client() currently builds a plain reqwest::Client::builder() path for this transport

Request

Please investigate the codex_apps streamable HTTP / RMCP handshake path for wham/apps under ChatGPT OAuth setups, especially when routed through configured proxy env. The endpoint itself is reachable, but the MCP initialize/initialized sequence fails.