Codex mcp login fails with OAuth providers that require resource (eg. MarketingCloud MCP)

[mishapavlov1]

What variant of Codex are you using?

App and CLI

What feature would you like to see?

Bug: codex mcp login fails with OAuth providers that require resource (MarketingCloud MCP)

Summary

codex mcp login marketingcloud-mcp starts an OAuth PKCE flow, but the generated OAuth requests appear to omit the resource parameter required by the provider.

• Without resource on the authorization request, the provider rejects the request.
• If I manually add resource to the authorization URL, browser login succeeds, but the CLI then fails on token exchange (which also appears to omit resource).

This looks like a bug/compatibility gap in MCP OAuth handling for providers that require OAuth resource indicators.

Environment

• codex-cli 0.104.0
• macOS arm64
• Date observed: 2026-02-23

MCP Server Config

• Name: marketingcloud-mcp
• URL: https://shared.marketingcloudmcp.com/mcp

Steps To Reproduce

1. Configure/register the MCP server (already configured in my case) with:
   • https://shared.marketingcloudmcp.com/mcp
2. Run:
   • codex mcp login marketingcloud-mcp
3. Open the browser authorization URL printed by Codex.

Expected Behavior

The OAuth login completes successfully and codex mcp login marketingcloud-mcp stores credentials.

Actual Behavior

Authorization step fails (CLI-generated URL)

Provider returns:

{"error":"invalid_request","error_description":"Missing or invalid response_type, client_id, redirect_uri, PKCE (code_challenge), or resource required","error_uri":"https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-3.1.1"}

The CLI-generated authorize URL included PKCE params, client_id, and redirect_uri, but did not include resource.

Manual workaround partially succeeds, then token exchange fails

If I manually add:

• resource=https://shared.marketingcloudmcp.com/mcp

to the authorization URL, the browser flow proceeds correctly.

After completing login in the browser, the waiting CLI process fails with:

Error: failed to handle OAuth callback

Caused by:
    OAuth token exchange failed: Server returned error response: invalid_request: Missing or invalid grant_type, code, redirect_uri, client_id, PKCE (code_verifier), or resource required (see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-3.1.3.1)

This suggests the token request also omits resource.

Workaround

Partial only:

• Manually patch the browser authorization URL to include resource=https://shared.marketingcloudmcp.com/mcp.

This gets past authorization, but the CLI still fails during token exchange.

Additional Notes

• codex mcp list showed marketingcloud-mcp auth as Unsupported in my environment, even though codex mcp login attempted OAuth.
• OAuth authorization server metadata is available at:
  • https://app.marketingcloudmcp.com/.well-known/oauth-authorization-server

Possible Cause / Suggested Fix (Hypothesis)

It looks like codex mcp login may not currently support OAuth providers that require a resource parameter (resource indicator).

One possible fix:

• Support an MCP OAuth resource value per server config (or infer it when available), and
• Include the same resource in both:
  • authorization request
  • token request

Additional information

No response

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• MCP OAuth login fails for Kapa-hosted Strapi docs server unless authorize URL includes resource parameter #11292

Powered by Codex Action

[mishapavlov1]

@etraut-openai it looks like a PR was made to address an earlier bug ticket but that didn't actually resolve issue

#11292

A user suggested a fix after issue was closed, pasted below

#11292 (comment)

Fix is available upstream

"This was fixed in rmcp v0.16.0 (released today) via modelcontextprotocol/rust-sdk#651, which brings the SDK into compliance with the 2025-11-25 MCP auth spec including RFC 8707 resource parameter binding. Codex currently uses rmcp 0.15 (#11539) and just needs to bump to 0.16."