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

[Chudroy]

What version of Codex CLI is running?

codex-cli 0.98.0

What subscription do you have?

Plus (ChatGPT account)

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Linux 6.8.0-40-generic x86_64 x86_64

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

VS Code integrated terminal (TERM=dumb)

What issue are you seeing?

codex mcp login fails for Strapi’s Kapa-hosted MCP server with OAuth callback error:

http://127.0.0.1:<port>/callback?error=server_error&error_description=An+unexpected+error+occurred&state=...

I can reproduce this consistently with:

• MCP URL: https://strapi-docs.mcp.kapa.ai
• Scope: openid
• Callback port fixed (mcp_oauth_callback_port = 4317) or ephemeral port

The server’s protected resource metadata is:

https://strapi-docs.mcp.kapa.ai/.well-known/oauth-protected-resource

which returns:

• "resource": "https://strapi-docs.mcp.kapa.ai/"
• "authorization_servers": ["https://mcp.kapa.ai/auth/google"]
• "scopes_supported": ["openid"]

From codex mcp login, the generated authorization URL includes scope=openid but does not include a resource query param.
When resource is missing, auth redirects back with error=server_error.

If I manually add this to the same authorize URL:

&resource=https%3A%2F%2Fstrapi-docs.mcp.kapa.ai%2F

the flow proceeds to consent instead of failing.

What steps can reproduce the bug?

1. Put this in ~/.codex/config.toml:

   mcp_oauth_callback_port = 4317
   
   [mcp_servers.strapi_docs]
   url = "https://strapi-docs.mcp.kapa.ai"
   enabled = true

Run:

bash

codex mcp login strapi_docs --scopes openid
Open the printed URL.
Observe callback error:
error=server_error&error_description=An+unexpected+error+occurred.
Optional validation:

Use the same printed authorize URL.
Append:
&resource=https%3A%2F%2Fstrapi-docs.mcp.kapa.ai%2F
Open modified URL.
Observe it redirects to consent flow instead of immediate callback error.


### What is the expected behavior?

codex mcp login should successfully complete OAuth for this MCP server without manual URL edits.

Specifically, when protected resource metadata includes a resource value, Codex should include that resource in the authorize request (or otherwise negotiate correctly) so the provider does not return server_error.

Additional information
This may be related to MCP OAuth protected-resource handling gaps (possibly related to #8889).



### Additional information

_No response_

[etraut-openai]

Thanks for the bug report.

Since this is specific to a single MCP server, this is likely to be a low priority for the Codex team to investigate. If someone from the community is interested in helping, we'd welcome an analysis of the problem and a proposed solution (not a PR, but a description here in the issue tracker).

[Emil-Sorensen]

Hi - I'm Emil, one of the co-founders of kapa.ai. We provide the hosted MCP infrastructure that Strapi (and many other companies) use for their docs servers.

The root cause here is that Codex CLI doesn't include the resource query parameter in the OAuth authorization request. Per MCP spec Section 8, clients MUST implement RFC 8707 Resource Indicators and include resource in both authorization and token requests. We use this parameter to identify which tenant the user is authenticating for, since our auth server handles multiple MCP deployments.

As @Chudroy confirmed, manually adding the resource parameter makes the flow work, which points to this being a client-side spec compliance gap.

Link: https://modelcontextprotocol.io/specification/draft/basic/authorization#resource-parameter-implementation

[markbackman]

Hi, I'm a maintainer of Pipecat. Today, we just released an MCP server using Kapa. We're getting reports of users having issues authenticating on Codex. I can confirm the MCP server works as expected on Claude Code.

The root cause here is that Codex CLI doesn't include the resource query parameter in the OAuth authorization request.
We'd be greatly appreciative if you resolved this issue in Codex 🙏

[etraut-openai]

OK, it sounds like this has broader impact and is something that we need to prioritize. Thanks for the reports.

[markbackman]

OK, it sounds like this has broader impact and is something that we need to prioritize. Thanks for the reports.

Thank you! 🙇

[etraut-openai]

PR is posted

[grahonan]

Thank you @etraut-openai !