Support OAuth for HTTP MCP servers from selected executor plugins

[jif-oai]

Why

#28522 routes selected-plugin HTTP MCP traffic through the owning executor, but OAuth bootstrap and refresh still used host-local clients. Executor-only servers therefore cannot complete discovery or login through the same network boundary as the MCP connection.

What changed

• adapt codex_exec_server::HttpClient to RMCP 1.8's OAuthHttpClient contract
• let RMCP own discovery, dynamic registration, PKCE, token exchange, and refresh
• route auth status, persisted-token startup, and app-server login through the server runtime while preserving the existing local discovery path
• add optional threadId to mcpServer/oauth/login and echo it in the completion notification
• implement RMCP's redirect policy and 1 MiB OAuth response limit over executor HTTP
• cover selected-thread OAuth discovery and login through an executor-only route

Depends on #28522.

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/app-server/tests/suite/v2/executor_mcp.rs

Line 113 in 81ae03d

"url": format!("http://{http_addr}/mcp"),

Make executor HTTP MCP test fail on host fallback

This binds the HTTP MCP to loopback, which the host ReqwestHttpClient can also reach, so the test still passes if executor HTTP MCP falls back to host routing. Please assert an executor-only routing signal/endpoint so this integration test catches that regression. guidance

---

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

Line 736 in 81ae03d

None => {

Cover dynamic client registration default path

This default branch is used when no oauth_client_id is configured, but the added authorization coverage only exercises Some(client_id). Please add a mock registration_endpoint test so dynamic registration and the returned credentials are verified. guidance

---

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

Line 1 in 81ae03d

use std::sync::Arc;

Split the OAuth plumbing into a smaller review

This non-mechanical OAuth plumbing changes 1022 lines across rmcp-client plus app-server/core/CLI wiring, exceeding the repo review-size guidance and making regressions hard to isolate. Please split rmcp-client OAuth client/tests from integration wiring. guidance

---

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

Line 99 in 81ae03d

std::sync::Arc::new(ReqwestHttpClient),

Preserve no_proxy for local OAuth discovery

On macOS when the local CLI/status path has system proxy configuration, this default discovery client again builds reqwest without no_proxy(). The deleted discovery code explicitly used Client::builder().timeout(...).no_proxy() to avoid the system-configuration panic, so supports_oauth_login can now crash before reporting unsupported OAuth.

---

codex/codex-rs/codex-mcp/src/mcp/auth.rs

Lines 258 to 260 in 81ae03d

	let http_client = runtime_context
	.resolve_streamable_http_client(server_name, config)
	.map_err(anyhow::Error::msg)?;

Short-circuit bearer auth before resolving runtime

When a streamable HTTP server is already authenticated via bearer_token_env_var or an Authorization header but its environment_id is unavailable to the status caller, this now fails while resolving the HTTP client before determine_streamable_http_auth_status can return BearerToken. For example, codex mcp list builds an EnvironmentManager::without_environments(), so those configured remote servers are reported as Unsupported even though no OAuth discovery request is needed.

---

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

Line 159 in 81ae03d

"grant_types": ["authorization_code", "refresh_token"],

Do not require refresh-token grants during registration

When an MCP OAuth server supports authorization-code login but does not issue refresh tokens, this dynamic-registration request can be rejected because it advertises the refresh_token grant as required. The client already handles token responses without a refresh token, so default login for those servers should not fail during registration just because refresh is unavailable.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".