Codex Routes MCP Auth Through the Executor, Because Tool Credentials Should Not Teleport Across Trust Boundaries

Codex’s latest MCP work is not glamorous, but it is the kind of change that decides whether coding agents become usable infrastructure or just very confident browser tabs with shell access. The headline is OAuth for executor-routed HTTP MCP servers. The actual story is sharper: OpenAI is making tool credentials follow the same trust boundary as the tool runtime.

That distinction matters because MCP is where an agent stops talking and starts doing. A model can suggest code all day without touching your systems. The moment it gets MCP access, it can read issue trackers, call internal docs, query observability systems, open browser tools, inspect design files, and route work through whatever a team has wired into its development loop. At that point, “where does this tool run?” and “whose credentials does it use?” are not implementation details. They are the security model.

OpenAI merged a cluster of Codex pull requests on June 25 that move the runtime in that direction. PR #28522 fixed selected executor plugins that declared Streamable HTTP MCP servers. Before the change, selected plugins could keep stdio MCP registrations while silently dropping HTTP declarations, which meant executor-owned HTTP servers never got the right network path. The fix retains Streamable HTTP declarations next to stdio declarations, routes HTTP clients through the owning executor environment, preserves local auth-header environment references, and rejects those references for executor-hosted declarations.

PR #28529 then made OAuth work through that same executor path. It adapted Codex’s exec-server HTTP client to RMCP 1.8’s OAuthHttpClient contract, letting RMCP own discovery, dynamic registration, PKCE, token exchange, and refresh while Codex keeps auth status, persisted-token startup, and app-server login tied to the selected server runtime. The change was not small: 38 files, 763 additions, and 96 deletions. A follow-up test PR, #29656, added an executor-only mock token endpoint and verified that PKCE token exchange actually reached the executor-only endpoint rather than leaking back through the host.

The boring boundary is the important boundary

The easy version of MCP support is a config parser and a happy-path HTTP client. The hard version is deciding who owns transport, auth, refresh, callback state, persisted tokens, and metrics when a plugin-selected server is not local. Codex is now doing more of the hard version.

That is good, because “remote” in an agent runtime is not just a deployment choice. A remote executor may have access to a private network the host cannot reach. It may be running in a sandbox with different filesystem rules. It may be attached to a specific thread, selected plugin, or remote environment. If Codex shows the user one MCP server but sends OAuth discovery, token exchange, or HTTP calls through a different environment, the user has no meaningful way to reason about authority. Worse, the failure mode looks like reliability until a credential crosses the wrong line.

The OAuth details are worth spelling out. MCP’s current authorization spec for HTTP-based servers leans on OAuth 2.1 concepts, Protected Resource Metadata, Authorization Server Metadata, Dynamic Client Registration, PKCE, and resource indicators. That is a lot of machinery for a developer tool, but it exists because bearer-token sprawl is how helpful integrations become ambient access. Codex now routes the relevant OAuth path through the selected executor runtime and enforces a 1 MiB OAuth response limit over executor HTTP. That limit is not a marketing bullet. It is the kind of defensive bound you add when your tool runtime is going to parse responses from systems outside the model’s core sandbox.

The ChatGPT session-auth changes in the same morning’s stack are even more direct. PR #29733 introduced use_chatgpt_auth for HTTP MCP servers, defaulting to false and honoring it only when the server URL shared the same HTTP(S) origin as the configured ChatGPT base URL. Then PR #29924 replaced that boolean with an exhaustive McpServerAuth enum supporting auth = "oauth" and auth = "chatgpt", with OAuth as the default.

That enum is more than cleanup. A boolean makes a credential-routing decision feel like a feature flag. An enum makes auth mode part of the protocol. More importantly, #29924 tightened the origin rule: ChatGPT auth is granted only to the origin derived from the hardcoded CHATGPT_CODEX_BASE_URL, not from an attacker-controlled chatgpt_base_url persisted in config. That is exactly the kind of boring, suspicious design agent platforms need. User-controlled config should not decide where first-party session credentials are allowed to go.

Telemetry is part of the security model

OpenAI also merged #29969, which adds MCP server-name attribution to call, duration, and error metrics and preserves bounded, sanitized error codes from every MCP server. On paper, this is observability. In practice, it is what lets operators tell the difference between a broken tool, a blocked policy gate, a rejected approval, a bad auth path, and a server-specific outage.

Agent systems fail strangely. A single user-visible “tool failed” can hide half a dozen causes: the model selected the wrong tool, the server rejected credentials, the runtime blocked a call, the executor could not reach the endpoint, the approval flow denied it, or the plugin declared a server the host could not access. If every non-Codex MCP error collapses to unknown, the team running the system cannot debug without transcript archaeology. Codex now uses the same metric-tagging path for blocked, rejected, and executed MCP calls, while sanitizing names and error codes. That is the right tradeoff: enough attribution to operate the system, not enough free-form detail to turn telemetry into an exfiltration channel.

The absence of public discussion around these PRs is almost the point. Hacker News searches for the obvious terms produced no relevant same-day thread. Auth routing through executor-owned MCP servers does not trend. It just prevents the future incident report where a coding agent authenticated to the wrong thing from the wrong place for reasons nobody could reconstruct.

For teams adopting MCP-heavy agents, the practical checklist is immediate. Treat every MCP server as a credential boundary, not a menu item. Verify whether stdio and HTTP transports follow different auth rules. Test OAuth discovery and token exchange from the same executor that will use the tool. Make explicit bearer headers take precedence over ambient session auth. Refuse to forward first-party session credentials to configurable origins. Add server attribution to metrics, but bound and sanitize anything that leaves the process. Most importantly, cover optional plugin-provided servers, executor-only routes, callback handling, and auth refresh in integration tests. Unit tests around config parsing will not catch the interesting failures.

The larger shift is that coding-agent security is moving past “ask before running dangerous commands.” Approval gates still matter, but approvals cannot save a runtime that cannot account for authority. If a tool is remote, auth must be remote-aware. If a credential is first-party, origin must be hardcoded or otherwise strongly pinned. If telemetry records tool failures, it needs server attribution without leaking server-provided strings. If a plugin brings an MCP server, the selected executor owns the network path.

Codex is tightening the layer where model intent becomes external capability. That is the layer that will matter most as teams connect agents to more than local files and shell commands. The product demo is the agent fixing code. The real product is the runtime knowing exactly which tool, credential, executor, origin, approval, and metric belonged to that fix.

Sources: OpenAI Codex PR #28529, PR #28522, PR #29656, PR #29733, PR #29924, PR #29969, OpenAI Codex MCP docs, MCP authorization specification