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?
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.
What version of the Codex App are you using?
Codex CLI 0.121.0 installed via
npm install -g @openai/codex, and reproduced withnpx -y @openai/codex@latest/ 0.122.0.What subscription do you have?
ChatGPT Business
What platform is your computer?
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:
When discovery is forced through a local HTTP metadata shim, it reaches dynamic client registration and then fails with:
Root cause
The MCP OAuth login path builds a raw reqwest client here:
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:
Repro
MCP config:
The server discovery metadata is reachable:
TLS checks:
succeeds.
fails with:
Then:
fails with:
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:
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 namegets 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 intoNo authorization support detected.