›_ Codex Issues
Codex Issues / #17529

Upgrade `rmcp` dependency to 1.4.0 to fix MCP HTTP/Cloudflare connection issues

Resolved 💬 4 comments Opened Apr 12, 2026 by tripleyoung Closed Aug 3, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Description

The Codex CLI and codex_apps currently depend on rmcp = "0.15.0".
As reported in multiple issues (e.g., #16485, #12859, #13852), this older version of the RMCP client lacks support for injecting custom HTTP headers (such as User-Agent or specific Auth headers) into Streamable HTTP and WebSocket handshakes. This causes MCP connections to fail behind Cloudflare, strict corporate proxies, or services like Supabase that require specific headers or constant re-authentication.

Proposed Solution

The rmcp crate has seen significant development and the 1.4.0 release introduces critical fixes for these exact problems:

  • StreamableHttpClient trait methods (post_message, delete_session, get_stream) now accept a headers parameter.
  • Extensive stability improvements to PaginatedRequestParams and the OAuthState machine.

We strongly recommend upgrading the rmcp dependency across the workspace to ^1.4.0.

Migration Effort

We have already successfully performed this migration in our downstream fork. Upgrading requires adapting to the new #[non_exhaustive] struct builders in rmcp::model::* (such as InitializeRequestParams, CallToolResult, ServerCapabilities, Implementation) and updating the StreamableHttpClient trait signatures in codex-rmcp-client.

If the maintainers are open to this upgrade, we would be happy to submit a Pull Request with the complete rmcp 1.4.0 migration to help close the aforementioned connection and auth issues.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #16485
  • #16550
  • #16360

Powered by Codex Action

CaseyLabs · 4 months ago

I believe I have just ran into this issue as well while using a local MiTM proxy on my machine. Notes:

Codex CLI fails in environments where HTTPS traffic is intercepted (e.g., local MITM proxy with a trusted root CA). Even when the custom CA is provided via:

export CODEX_CA_CERTIFICATE=/path/to/corporate-root-ca.pem

Codex still fails to complete critical HTTPS flows:

  • MCP startup (codex_apps) → fails during handshake to https://chatgpt.com/backend-api/wham/apps
  • OAuth login → fails during token exchange at https://auth.openai.com/oauth/token
  • Device auth → fails at https://auth.openai.com/api/accounts/deviceauth/usercode

Key observations

  • DNS, TCP, and TLS all succeed
  • Endpoints are reachable via curl
  • Responses are returned (including expected 405 for wrong method)
  • However, Cloudflare injects a challenge (cf-mitigated: challenge) when traffic is proxied/intercepted
  • Codex CLI fails with:

``
error sending request for url (...)
``

instead of handling or surfacing the challenge

  • Providing a custom CA via CODEX_CA_CERTIFICATE does not resolve the issue

Likely root cause

Cloudflare challenge incompatibility

  • Codex HTTP/MCP client cannot handle WAF challenge responses
  • Receives non-JSON/HTML challenge instead of expected API response
aadnehovda · 3 months ago

Will the new version allow codex to pass scopes in the registration part of DCR flow?

ofek · 1 month ago

@etraut-openai This can be closed as the version on main is 1.8.0 now.

https://github.com/openai/codex/blob/129ea2aaf5fb426d8ba683ee53f290742f41dd31/codex-rs/Cargo.toml#L376