[MCP OAuth] Trusted private-IP authorization server rejected after rmcp 3.5.1 upgrade #55163

Observed behavior

On 2026-10-16, Windows Codex CLI 0.163.0-alpha.10.2 failed to initialize an OAuth-protected enterprise MCP connection. The same failure was reproduced on two computers and during an independent CLI login-discovery check, before the browser authorization step.

The MCP resource, protected-resource metadata and authorization server use the same HTTPS origin on an RFC1918 IPv4 address. Normal HTTPS requests validate the certificate successfully; health and both discovery documents return HTTP 200 with valid JSON. The advertised authorization-server URL agrees with its metadata issuer.

Sanitized errors:

rejecting authorization server metadata URL `https://<private-ip>:<port>/`
failed to resolve OAuth metadata before using stored credentials
protected resource metadata ... names authorization servers ...,
but none published usable metadata

Reproduction

1. Configure an OAuth MCP server at a private IPv4 HTTPS origin, with a certificate trusted by the Windows user.
2. Publish same-origin protected-resource metadata with resource and authorization_servers, and authorization-server metadata with matching issuer, authorization/token/registration endpoints and S256 PKCE support.
3. Connect through native Codex HTTP MCP OAuth using stored credentials, or attempt CLI OAuth login discovery.
4. Observe discovery rejection before tools become available.

Version analysis — source comparison, not runtime A/B testing

• Codex 0.162.1 and 0.163.0-alpha.6 pin rmcp 3.3.0.
• 0.163.0-alpha.8 pins rmcp 3.5.1, following Codex #52972.
• rust-sdk #935 introduced the private authorization-server URL check.
• rust-sdk #1264 changed an unusable advertised authorization-server result from fallback to an error. This appears to explain the failure after the dependency upgrade.
• Source inspection on 2026-10-19 found the same relevant rejection/error paths in the dependencies used by 0.163.0 and 0.164.0-alpha.3. Those releases and a rollback to 0.162.1 have NOT been runtime-tested for this report.

Expected behavior / requested clarification

Please confirm a supported secure configuration for an explicitly trusted, same-origin enterprise private-IP OAuth authorization server, or provide narrowly scoped support with appropriate trust controls. Please preserve SSRF protections for untrusted discovery targets.

This report concerns the native HTTP MCP OAuth path. It contains no credentials, real network addresses, tenant/application identifiers, account details, conversation IDs, private hostnames, or raw diagnostic attachments.