codex mcp login fails against TLS 1.3-only OAuth providers on macOS

Open 💬 1 comment Opened Apr 21, 2026 by andreaslordos

What version of the Codex App are you using?

Codex CLI 0.121.0 installed via npm install -g @openai/codex, and reproduced with npx -y @openai/codex@latest / 0.122.0.

What subscription do you have?

ChatGPT Business

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

codex mcp login <server> fails against an MCP OAuth provider behind a TLS-1.3-only HTTPS endpoint on macOS.

The command fails immediately with:

Error: No authorization support detected

When discovery is forced through a local HTTP metadata shim, it reaches dynamic client registration and then fails with:

Error: Registration failed: Dynamic registration failed: Registration failed: HTTP request error: error sending request for url (...)

Root cause

The MCP OAuth login path builds a raw reqwest client here:

codex-rs/rmcp-client/src/perform_oauth_login.rs

let http_client = apply_default_headers(ClientBuilder::new(), &default_headers).build()?;

On macOS this can select the native TLS backend. I captured the ClientHello from released Codex and it did not advertise TLS 1.3:

{
  "handshake_version": "3.3",
  "supported_versions": [],
  "cipher_suites": [
    "00ff", "c02c", "c02b", "c024", "c023", "c00a", "c009", "c008",
    "c030", "c02f", "c028", "c027", "c014", "c013", "c012", "009d",
    "009c", "003d", "003c", "0035", "002f", "000a"
  ]
}

Against a TLS-1.3-only Cloudflare edge, the underlying reqwest/native-tls error is:

reqwest::Error {
  kind: Request,
  url: "https://someurl/oidc/register",
  source: hyper_util::client::legacy::Error(
    Connect,
    Error { code: -9836, message: "bad protocol version" }
  )
}

Repro

MCP config:

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

The server discovery metadata is reachable:

curl -i https://someurl.ai/.well-known/oauth-authorization-server/mcp
curl -i https://someurl.ai/.well-known/oauth-authorization-server

TLS checks:

openssl s_client -connect someurl.longlake.ai:443 \
  -servername someurl.longlake.ai \
  -tls1_3

succeeds.

openssl s_client -connect someurl.longlake.ai:443 \
  -servername someurl.longlake.ai \
  -tls1_2

fails with:

tlsv1 alert protocol version

Then:

codex mcp login --scopes name:all name

fails with:

Error: No authorization support detected

Expected behavior

Codex should negotiate TLS 1.3 and proceed to OAuth dynamic client registration / authorization URL generation.

Tested fix

Changing the OAuth login client construction to force rustls fixes the issue:

let http_client = apply_default_headers(
    ClientBuilder::new().use_rustls_tls(),
    &default_headers,
)
.build()?;

With that local patch, Codex advertises TLS 1.3 in the ClientHello:

{
  "supported_versions": ["TLS 1.3", "TLS 1.2"],
  "cipher_suites": ["1302", "1301", "1303", "..."]
}

and codex mcp login --scopes name:all name gets past discovery/DCR and prints the OAuth authorization URL.

Suggested fix: force rustls for the MCP OAuth login reqwest client in codex-rs/rmcp-client/src/perform_oauth_login.rs. It would also help to surface the underlying TLS error instead of collapsing it into No authorization support detected.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗