codex mcp login for Atlassian Rovo reaches consent, then returns invalid_request before callback

What version of Codex CLI is running?

codex-cli 0.146.0-alpha.3.1

What subscription do you have?

ChatGPT subscription via Codex Desktop

Which model were you using?

N/A — failure occurs in codex mcp login before a model session

What platform is your computer?

Darwin 25.5.0 arm64 arm

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

Codex Desktop embedded terminal / zsh

Codex doctor report

Not attached because the current report contains local filesystem paths and unrelated diagnostics from a network-restricted agent environment. Relevant sanitized fields: Codex 0.146.0-alpha.3.1, runtime macos-aarch64, and a configured Streamable HTTP MCP server. No Atlassian credential was stored because the callback never occurred.

What issue are you seeing?

codex mcp login against Atlassian's official Streamable HTTP endpoint completes OAuth discovery and dynamic client registration, and Atlassian renders a consent page for the selected site. After clicking Accept, Atlassian replaces the consent page with:

invalid_request
Incorrect request parameters

The browser never reaches Codex's generated http://127.0.0.1:<port>/callback/<id> URI, so the CLI listener receives no code and keeps waiting. No credential is stored; codex mcp list still reports the server's authentication as Unsupported.

This reproduced in an isolated Chromium context and a fresh Safari window after closing stale OAuth tabs, using only the three read-only scopes currently advertised by Atlassian's protected-resource metadata. I redacted the Atlassian account and site, client ID, state, PKCE values, callback ID, and full authorization URLs.

Because the provider renders consent and then rejects the request, I cannot determine from the client side whether the incompatible parameter originates in Codex's dynamic-client metadata, the authorization request, or Atlassian's backend.

What steps can reproduce the bug?

1. Configure the official endpoint:

``toml
[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v1/mcp/authv2"
``

1. Confirm the endpoint's protected-resource metadata advertises read:account, read:me, and read:jira-work.
2. Run:

``console
codex mcp login atlassian --scopes read:account,read:me,read:jira-work
``

1. In the Atlassian consent page, select a valid Jira site. The page displays the requested Read/Search permissions.
2. Click Accept.
3. Observe invalid_request / Incorrect request parameters. The loopback callback is never loaded and the CLI continues waiting.

What is the expected behavior?

After Accept, Atlassian should redirect to Codex's generated loopback callback, Codex should exchange the authorization code and persist the credential, and the server should report OAuth authentication instead of Unsupported.

Additional information

Controls and related context:

• No oauth_resource or mcp_oauth_callback_url override is configured; Codex generated an ephemeral 127.0.0.1 callback.
• Atlassian's supported-domain policy was enabled. Its official domain list explicitly includes 127.0.0.1 and localhost for OAuth clients.
• Atlassian also documents that a domain setting can appear correct in its Admin UI without being committed to its backend enforcement service (support article). I did not change organization settings or make another authorization attempt after the clean reproduction.
• The clean retry omitted search:jira-work because the live protected-resource metadata does not advertise it.
• Atlassian's OAuth 2.1 documentation recommends https://mcp.atlassian.com/v1/mcp/authv2 for custom clients.
• This appears related but not identical to #35253: explicit resource scopes reach consent here, then fail on Accept. It is also distinct from #34467 (duplicate resource only when oauth_resource is set), #34684 (failure before browser authorization support is detected), and #30460 (explicit callback override not used exactly).

Could maintainers inspect whether the generated DCR registration and authorization request are compatible with Atlassian's consent backend, or identify which parameter the provider is rejecting after consent? A sanitized diagnostic showing the DCR response and final authorization parameter names would help isolate the interoperability failure.