`no_proxy()` in OAuth discovery breaks MCP login behind HTTPS proxies

Start in codex-rs/rmcp-client/src/auth_status.rs at the reqwest client used for OAuth discovery, then compare it with the client in perform_oauth_login.rs. Reproduce with HTTPS_PROXY configured and direct outbound access blocked. Done means the .well-known/oauth-authorization-server request respects the configured proxy and codex mcp login <server-name> completes discovery.

What version of Codex CLI is running?

0.130.0

What subscription do you have?

Enterprise

Which model were you using?

No response

What platform is your computer?

macOS

What terminal emulator and version are you using (if applicable)?

No response

Codex doctor report

What issue are you seeing?

The .no_proxy() to the reqwest client used for OAuth discovery in codex-rs/rmcp-client/src/auth_status.rs:89 breaks MCP OAuth login in environments where all outbound traffic must route through a corporate HTTPS proxy. Many enterprise setups use mandatory forward proxies for security policy enforcement, credential injection, or network isolation. In these environments, direct connections are blocked at the network level — processes can only reach external hosts via the configured HTTPS_PROXY.

With .no_proxy(), the OAuth discovery request bypasses the proxy and fails because the direct connection is refused.

What steps can reproduce the bug?

1. Configure an environment where HTTPS_PROXY points to a mandatory forward proxy and direct outbound connections are blocked (e.g., corporate firewall, sandbox, VPN split-tunnel)
2. Configure a streamable HTTP MCP server (e.g., in config.toml)
3. Run codex mcp login
4. OAuth discovery times out or fails with a connection error because the .no_proxy() client cannot reach the .well-known/oauth-authorization-server endpoint directly

What is the expected behavior?

The OAuth discovery client should respect HTTPS_PROXY / HTTP_PROXY environment variables, like every other HTTP client in the codebase. The discovery request should route through the configured proxy so it works in environments where proxy use is mandatory.

Additional information

The actual login flow in perform_oauth_login.rs correctly uses ClientBuilder::new() without .no_proxy() — so the transport client respects the proxy. Only the discovery path is broken.

If the system-configuration crash is a concern, then build the client without it, explicitly use ENV vars only. Example:

let mut builder = Client::builder().timeout(DISCOVERY_TIMEOUT).no_proxy();
  if let Ok(url) = std::env::var("HTTPS_PROXY")
      .or_else(|_| std::env::var("https_proxy"))
      .or_else(|_| std::env::var("HTTP_PROXY"))
      .or_else(|_| std::env::var("http_proxy"))
  {
      if let Ok(proxy) = reqwest::Proxy::all(&url) {
          builder = builder.proxy(proxy);
      }
  }