[BUG] OAUTH2 Warp does not send client_id to MCP server OAUTH2 /token endpoint

[symdeb]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

method:POST
request headers:
accept:application/json
content-type:application/x-www-form-urlencoded
authorization:Basic czZCaGRSa3F0MzpjZjEzNmRjM2MxZmM5M2YzMTE4NWU1ODg1ODA1ZA==
accept-encoding:gzip,br
host:localhost
content-length:153
URL: /api/oauth/token
Query:
Query Parameters:
contents:
grant_type=authorization_code&code=g0ZGZmNjVmOWI&code_verifier=FBQUrivV9MqXyBbqsJHF4EDfMVFHu8fPciVZrD5QWyg&redirect_uri=warp%3A%2F%2Fmcp%2Foauth2callback

Missing client_id.

To reproduce

Connect to locahost streaming http(s) MCP server

Expected behavior

send the client_id obtained from the OAUTH2 server to the token endpoint

Screenshots, videos, and logs

2026-05-18 10:20:16.706 | [error] MCP: Failed to connect to server: Transport creation error: OAuth token exchange failed: Server returned error response: unauthorized_client: Token request rejected. Check the client id in inspector, it must be s6BhdRkqt3, but got client_id: (see http://localhost/api/oauth/token)

Operating system (OS)

Linux

Operating system and version

25.10 kernel 7.0.7

Shell Version

No response

Current Warp version

v0.2026.05.13.09.15.stable_03

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@symdeb

Here's what I found while triaging this issue:

The token request appears to include the registered client credentials via HTTP Basic auth, but not as a client_id form field. This looks like an MCP OAuth interoperability issue with servers that require client_id in the token request body.

I have a few follow-up questions before I can narrow this down:

1. Which Warp version and channel reproduced this, and does it still happen after updating to the latest Warp build?
2. Can you share which OAuth/MCP server implementation is running on localhost, or the redacted token-endpoint validation logic showing why it rejects HTTP Basic auth unless client_id is also in the form body?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that MCP OAuth token exchange fails against a localhost streaming HTTP MCP server because the form-encoded /token request omits client_id, even though the request appears to authenticate the registered client via HTTP Basic auth..

Triage

This looks like an MCP OAuth token-exchange compatibility bug. The request evidence shows Warp reaches the OAuth /token endpoint with the authorization code and PKCE verifier, but the form body does not include client_id; at the same time, the request includes HTTP Basic client authentication, so Warp does appear to be sending the registered client credentials in another OAuth-supported location.

Current code routes OAuth-protected streamable HTTP/SSE MCP servers through determine_transport and oauth::make_authenticated_client, then delegates dynamic client registration and token exchange behavior to rmcp. That makes this likely an interoperability issue between the rmcp token request shape used by Warp and OAuth servers that require client_id in the form body even when Basic auth is present.

Reproducibility

Medium. The reporter provided the exact failing request shape and Warp error, but the issue depends on a localhost OAuth/MCP server implementation and the current Warp version is not included.

Duplicate check

I scanned open issues and recently closed issues. #8356 is related MCP OAuth/DCR traffic, but I found fewer than two strong duplicate matches, so this should not be marked as a duplicate by the repository dedupe threshold.

Likely code areas

• app/src/ai/mcp/templatable_manager/oauth.rs — constructs the MCP OAuth auth manager, redirect URI, DCR/static client config, callback handling, and credentials persistence.
• app/src/ai/mcp/templatable_manager/native.rs — detects HTTP 401 during MCP transport preflight and invokes the OAuth client path before retrying the MCP initialize request.
• Cargo.toml / Cargo.lock — current rmcp dependency version that owns most of the OAuth token request construction.

Follow-up needed

The key remaining ambiguity is whether the reporter's OAuth server intentionally rejects Basic-authenticated token requests unless client_id is also present in the form body, and whether this reproduces on the latest Warp build.

Question reasoning

1. Which Warp version and channel reproduced this, and does it still happen after updating to the latest Warp build? — The issue omits Warp version, and MCP OAuth behavior has changed recently enough that maintainers need the build/channel to know which code path produced the request.
2. Can you share which OAuth/MCP server implementation is running on localhost, or the redacted token-endpoint validation logic showing why it rejects HTTP Basic auth unless client_id is also in the form body? — The captured request appears to send the client credentials in the Basic auth header, so the server's expected client-auth method is needed to confirm whether Warp/rmcp should also send a body client_id for compatibility.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[symdeb]

Warp v0.2026.05.13.09.15.stable_03

PerOauth2 spec: The OAuth 2.0 token endpoint is the server URL where your application exchanges an authorization code, client credentials, or refresh token for a functional access token. To use this endpoint securely, your client_id acts as a public identifier for your application.

There is not client_id in the request from WARP as stated above so the request is invalid. HTTP Basic Authentication is a simple, built-in method where a client sends a username and password encoded in Base64 within the request header.

That is not OAuth2 and totally unrelated to this topics

[oz-for-oss]

@symdeb

Here's what I found while triaging this issue:

The request appears to include the registered client ID in the HTTP Basic auth username rather than in the form body. This still fails against your server, so the likely compatibility issue is the token endpoint auth method Warp/rmcp selected for this MCP OAuth server.

I have a few follow-up questions before I can narrow this down:

1. Can you share the authorization server metadata document for this localhost server, especially token_endpoint_auth_methods_supported, with any secrets redacted?
2. Can you share the dynamic client registration response Warp receives, with client_secret and tokens redacted?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that MCP OAuth token exchange fails because Warp/rmcp sends the dynamically registered client ID via HTTP Basic auth rather than as a form client_id parameter, and the server rejects that token request..

Triage summary

This looks like an MCP OAuth compatibility bug in the token-exchange path. Warp reaches the OAuth /token endpoint, but the server rejects the request because it is looking for client_id in the application/x-www-form-urlencoded body while Warp/rmcp is authenticating the dynamically registered client with HTTP Basic.

Evidence from the report:

• The failed request body includes grant_type=authorization_code, code, code_verifier, and redirect_uri, but no form client_id.
• The request does include an Authorization: Basic ... header, and the Basic username decodes to the same client ID named in the server error.
• Current Warp MCP OAuth code delegates the exchange through rmcp::transport::auth from app/src/ai/mcp/templatable_manager/oauth.rs; the HTTP/SSE startup path is in app/src/ai/mcp/templatable_manager/native.rs.
• Warp currently pins rmcp = 1.6, whose OAuth client configuration defaults to HTTP Basic when a client secret is present unless the authorization-server metadata advertises only client_secret_post.

Most likely this is not a missing-client-ID-in-memory bug. It is more likely an auth-method negotiation/interoperability issue: either the authorization server should advertise client_secret_post and Warp/rmcp should honor it, or the server rejects valid client_secret_basic credentials despite Warp/rmcp selecting that method. The next debugging step is to inspect the server's authorization metadata and DCR response to see which token endpoint auth method Warp/rmcp should be using.

Question reasoning

1. Can you share the authorization server metadata document for this localhost server, especially token_endpoint_auth_methods_supported, with any secrets redacted? — This determines whether Warp/rmcp should be using client_secret_basic, client_secret_post, or a public-client token request for this server.
2. Can you share the dynamic client registration response Warp receives, with client_secret and tokens redacted? — The DCR response will show whether the server issued a client secret and whether it declared a token endpoint authentication method that differs from the request Warp ultimately sent.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[symdeb]

This is no locahost

Per AI: you need to send it Verify your Configuration: Ensure the client_id and client_secret are explicitly set in the request body as form-urlencoded parameters (e.g., grant_type=authorization_code**&client_id=YOUR_ID**&client_secret=YOUR_SECRET) rather than relying purely on HTTP headers.

DCR return:

method:POST
request headers:
content-type:application/json
accept:/
accept-encoding:gzip,br
host:localhost
content-length:183
URL: /api/oauth/register
Query:
Query Parameters:
contents:
{"client_name":"Warp","redirect_uris":["warp://mcp/oauth2callback"],"grant_types":["authorization_code","refresh_token"],"token_endpoint_auth_method":"none","response_types":["code"]}
INFO: The request is to the Insecure url (http)
endpoint------------ GET REGISTER------------

Response returned:

{"client_id":"s6BhdRkqt3","client_secret":"cf136dc3c1fc93f31185e5885805d","client_id_issued_at":1779070802,"client_id_expires_at":1779070802,"grant_types":["authorization_code","refresh_token"],"redirect_uris":["warp://mcp/oauth2callback"]}

I am tired to talk to a bot for an obvious bug. You know, go ... yourself.

[oz-for-oss]

@symdeb

Here's what I found while triaging this issue:

Thanks for adding the DCR request/response. This now looks like an actionable MCP OAuth bug: Warp registers the MCP OAuth client as token_endpoint_auth_method=none, but the token request can still be sent with HTTP Basic when the registration response includes a secret, so servers expecting a public-client token request reject it.

Maintainer details

I concluded that warp's MCP OAuth DCR flow appears to register as a public client but then sends the token exchange with Basic client authentication when a client_secret is returned, causing servers expecting client_id in the form body to reject the request..

Triage summary

This looks like an actionable MCP OAuth bug rather than a missing-info report. The reporter's follow-up includes the Dynamic Client Registration response showing client_id and client_secret, followed by a token request that uses HTTP Basic auth and omits client_id from the application/x-www-form-urlencoded body, producing unauthorized_client.

Reproduction confidence

High. The report includes the exact registration and token endpoint payloads plus the Warp version, and current code inspection matches the captured behavior for MCP OAuth servers that return a non-empty client_secret even though Warp requested token_endpoint_auth_method: none.

Likely root cause

Warp's MCP OAuth path in app/src/ai/mcp/templatable_manager/oauth.rs delegates DCR and callback handling to rmcp via OAuthState::start_authorization and oauth_state.handle_callback. Warp is pinned to rmcp 1.6.0. In that crate, DCR sends token_endpoint_auth_method: "none", but register_client still carries forward any non-empty client_secret returned by the server. configure_client then sets that secret on the OAuth client and defaults to client_secret_basic unless authorization-server metadata advertises only client_secret_post; it does not preserve the DCR-selected none method for the token request.

Duplicate check

I scanned the open issue list for MCP/OAuth/token-exchange/client_id reports. Related issues such as #8356, #8624, #8020, and #9462 cover adjacent MCP OAuth failures, but none match this specific DCR token_endpoint_auth_method=none + token endpoint client_id omission failure closely enough to mark this as a duplicate.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz