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

Resolved 💬 8 comments Opened Feb 10, 2026 by Chudroy Closed Feb 12, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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?

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

```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_

View original on GitHub ↗

8 Comments

etraut-openai contributor · 5 months ago

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 · 5 months ago

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 · 5 months ago

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 contributor · 5 months ago

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

markbackman · 5 months ago

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

Thank you! 🙇

etraut-openai contributor · 5 months ago

PR is posted

grahonan · 5 months ago

Thank you @etraut-openai !

ekarcnevets · 5 months ago

Hi @etraut-openai thanks for looking into this. I wanted to report that this issue is not fixed in the latest release which includes the rmcp 0.15 bump.

The rmcp 0.15 bump (#11539) fixed an OAuth discovery fallback regression, but it seems not the missing resource parameter.

Reproduction on Codex 0.102.0 (latest)

$ codex --version
codex-cli 0.102.0

$ codex mcp add squad --url=https://mcp.meetsquad.ai/mcp
Added global MCP server 'squad'.
Detected OAuth support. Starting OAuth flow…
Authorize `squad` by opening this URL in your browser:
https://auth.meetsquad.ai/oauth/2.1/authorize?response_type=code&client_id=d5a2f5f48d84e3fc6bc3316b534a368c&state=zOEZEm8JY--f7nyXi_A_3A&code_challenge=1KdtEWF4KzjpmlCP0GwgsKEc5N3uGCKwAcoh7VT1Es0&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3A52915%2Fcallback

The authorization URL has no resource parameter. The browser callback returns:

OAuth error: Missing or invalid resource.

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.