›_ Codex Issues
Codex Issues / #28830

oauth_resource causes duplicate resource parameters in MCP OAuth authorization request

Open 💬 2 comments Opened Jun 18, 2026 by maron8676

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.611.62324

What subscription do you have?

ChatGPT Business (organization-managed account)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

I'm trying to connect a Streamable HTTP MCP server that requires OAuth authentication from the Codex app.

During the OAuth flow, the MCP client needs to send a request to the IdP's /authorize endpoint. This request includes a resource parameter.

For our IdP (Microsoft Entra ID), the required value of resource is not the MCP server URL. Instead, it must be a value in the format:

api://<client-id>

Codex provides an oauth_resource configuration option for MCP servers, so I assume this is the intended way to specify a custom resource value.

Actual Behavior

When oauth_resource is configured, the authorization request generated by Codex contains the resource parameter twice.

For example:

https://login.microsoftonline.com/.../oauth2/v2.0/authorize
  ?client_id=...
  &response_type=code
  &redirect_uri=...
  &scope=...
  &resource=https://mcp.example.com
  &resource=api://<client-id>

It appears that Codex:

  1. Automatically derives a resource value from the MCP server URL, and
  2. Adds the value specified in oauth_resource

As a result, the request contains duplicate resource parameters, and Microsoft Entra ID rejects the request.

What steps can reproduce the bug?

  1. Configure a Streamable HTTP MCP server that uses OAuth authentication with Microsoft Entra ID.
  2. Set oauth_resource in the MCP server configuration to a value such as:

api://<client-id>

  1. Start the OAuth login flow from the Codex app.
  2. Inspect the request sent to the IdP's /authorize endpoint.
  3. Observe that the authorization request contains two resource parameters:
  • One derived from the MCP server URL.
  • One from the configured oauth_resource value.
  1. Observe that Microsoft Entra ID rejects the authorization request because of the duplicate resource parameters.

What is the expected behavior?

When oauth_resource is specified, Codex should use that value as the sole resource parameter and should not automatically add a second value derived from the MCP server URL.

Expected request:

&resource=api://<client-id>

Additional information

I found previous discussions related to support for the OAuth resource parameter (RFC 8707), and oauth_resource appears to have been introduced for this purpose.

However, the issue I'm seeing is not that resource cannot be specified, but that specifying oauth_resource results in duplicate resource parameters being included in the authorization request.

View original on GitHub ↗

2 Comments

XVincentX · 2 months ago

I am having the same issue - Codex seems to insist that one resource with the URL of the MCP server has to be sent regardless. This is likely because of the https://datatracker.ietf.org/doc/rfc9728/ spec

Either this is a bug or they need to clarify that such parameter is only for "additional" resources in the URL.

Hopefully they will address/clarify it soon

boguslaw-los · 25 days ago

Additional repro from Codex CLI 0.146.0 on macOS, with Microsoft Entra / Power BI remote MCP impact.

I think the root problem is slightly broader than duplicate oauth_resource: Codex appears to ignore the resource value advertised by OAuth Protected Resource Metadata and still derives the OAuth resource parameter from the MCP server URL.

Minimal local repro:

  1. Run a local Streamable HTTP test MCP endpoint at http://127.0.0.1:9876/mcp.
  2. Have GET /mcp return 401 with:

WWW-Authenticate: Bearer resource_metadata="http://127.0.0.1:9876/.well-known/oauth-protected-resource"

  1. Have GET /.well-known/oauth-protected-resource return:

``json
{
"resource": "https://analysis.windows.net/powerbi/api",
"authorization_servers": [
"https://login.microsoftonline.com/<tenant-id>/v2.0"
],
"bearer_methods_supported": ["header"],
"scopes_supported": [
"https://analysis.windows.net/powerbi/api/Dataset.Read.All",
"https://analysis.windows.net/powerbi/api/MLModel.Execute.All",
"https://analysis.windows.net/powerbi/api/Workspace.Read.All"
]
}
``

  1. Add/login:

``sh
codex mcp add codex-resource-metadata-test --url http://127.0.0.1:9876/mcp --oauth-client-id <redacted-public-client-id>
codex mcp login codex-resource-metadata-test
``

Observed authorization URL:

...&scope=openid+profile+email+offline_access&resource=http%3A%2F%2F127.0.0.1%3A9876%2Fmcp

Expected authorization URL should use the protected-resource metadata resource:

...&resource=https%3A%2F%2Fanalysis.windows.net%2Fpowerbi%2Fapi

Real-world impact:

The official Microsoft Power BI remote MCP endpoint is:

https://api.fabric.microsoft.com/v1/mcp/powerbi

Power BI delegated scopes are under:

https://analysis.windows.net/powerbi/api/...

Codex builds an Entra authorize/token flow with a resource derived from the MCP URL instead of the protected resource / Power BI API resource. Microsoft Entra rejects the flow with:

AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes.

This is not an app registration or tenant consent problem. The same Power BI MCP endpoint works when called with a bearer token acquired separately for either https://api.fabric.microsoft.com or https://analysis.windows.net/powerbi/api.

Requested behavior:

  • If protected-resource metadata contains resource, Codex should use that value as the OAuth resource indicator instead of deriving it from the MCP endpoint URL.
  • If oauth_resource is configured, it should replace the derived/metadata resource, not append an additional resource parameter.
  • The same resource value should be used consistently for authorize, token exchange, and refresh.