Warp icon indicating copy to clipboard operation
Warp copied to clipboard

WARP stops OAuth2 cycle after 401 from MCP server and /register call to authorization server

Open symdeb opened this issue 1 month ago • 2 comments

Describe the bug

See attached file

warp.log

To reproduce

  1. Return a 401 upon Warp calling an MCP server without a valid access token.
  2. Observer the calls to the OAuth2 server in the attached file
  3. Warp gives up after calls to /register

Expected behavior

Warp to continue the Oauth2 flow (login/consent screen, obtain a code and get access token)

Operating system and version

Ubuntu 25.04

Does this block you from using Warp daily?

Yes

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals. (MCP Inspector does this correctly)

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

None

symdeb avatar Nov 11 '25 05:11 symdeb

Any ideas ? the response is according to rfc8414

The logs show: 2025-11-14 23:13:09.196 | [note] Attention! There may be sensitive information (such as API keys) in these logs. Make sure to redact any secrets before sharing with others. 2025-11-14 23:13:09.229 | [error] MCP: preflight connection to MCP server failed: Transport creation error: Registration failed: analyze response error: error decoding response body 2025-11-14 23:13:09.229 | [error] MCP: Failed to connect to server: Transport creation error: Registration failed: analyze response error: error decoding response body

Warp does not sent an OPTIONS (pre-flight) request to the server at all. Here are the incoming requests to the server. 127.0.0.1 - - [14/Nov/2025:23:35:20 +0800] "POST /api/mcp/mcp HTTP/1.1" 401 366 "-" "-" 127.0.0.1 - - [14/Nov/2025:23:35:20 +0800] "GET /.well-known/oauth-authorization-server/api/mcp/mcp HTTP/1.1" 200 810 "-" "-" 127.0.0.1 - - [14/Nov/2025:23:35:20 +0800] "POST /api/oauth/register HTTP/1.1" 201 536 "-" "-" 127.0.0.1 - - [14/Nov/2025:23:35:20 +0800] "POST /api/oauth/register HTTP/1.1" 201 536 "-" "-" 127.0.0.1 - - [14/Nov/2025:23:35:20 +0800] "GET /.well-known/oauth-authorization-server/api/mcp/mcp HTTP/1.1" 200 810 "-" "-"

symdeb avatar Nov 14 '25 15:11 symdeb

Try these steps to see if they resolve the issue you're seeing.

leesa-ui-w avatar Dec 10 '25 20:12 leesa-ui-w

Moved on to PHP8. PHP8 moves CORS header responses from .htaccess to the PHP scripts. MCP Inspector now works fine, but Warp reports a pre-flight error. Cannot find any information WHY it fails. it seems there is no documentation on what headers WARP expects. it seems the implementation of streaming http and CORS is inconsistent between many MCP hosts.

tail -f "/home/user/.local/state/warp-terminal/mcp/XRNSiMBQn7aDqJYhB7PUPA.log" 2025-12-20 09:28:18.827 | [note] Attention! There may be sensitive information (such as API keys) in these logs. Make sure to redact any secrets before sharing with others. 2025-12-20 09:28:18.848 | [error] MCP: preflight connection to MCP server failed: Transport creation error: error sending request for url (https://localhost/api/mcp/mcp) 2025-12-20 09:28:18.848 | [error] MCP: Failed to connect to server: Transport creation error: error sending request for url (https://localhost/api/mcp/mcp) ^C

After further checking, the reason why connection failed is because WARP did not send an access token with calls to the MCP server. After hacking this and bypass the access token check on the server, WARP connects to the MCP server fine

WARP does look for an authorization server and calls the .well_known endpoint, but it never proceeds a redirects to the consent page for authorization so it never obtain an authorization code and then an token .

So not sure why WARP reports this as a "PREFLIGHT" error , does not get an token, it seems the failure got nothing to do with CORS WARP still proceeds to attempt to access MCP server. w/o a token This is very INSECURE ! it should never access the MCP server if it does not have a access token.

When enabling Figma or Git MCP server, it does start the web-browser login page for those services

The docs state: 1 Starting a server without existing credentials automatically opens a browser-based authentication flow. 2 Credentials can be revoked at any time from the MCP Servers pane in Warp. the first does not happen and for the 2nd I don't see such option in WARP. I did try rm -rf ~/.mcp-auth but the authorization endpoint (page) is still not launched.

oauth.zip

Attached is the OAUTH2 log.

This is the inspector OAUTH2 flow.

Image

symdeb avatar Dec 20 '25 01:12 symdeb

Here are the response from the localhost and Figma. . When using https:// (self signed cartificate) Warp raises the error

Image

when using http, it does not call the authentication endpoint, but just connects to the MCP server. While for Figma it opens the browser.

Response elements are the same. This all does work in MCP insepctor with http and https

{"resource":"https://localhost/api/mcp/mcp","resource_name":"Local MCP","authorization_servers":["https://localhost/api/oauth"],"bearer_methods_supported":["header"],"resource_documentation":"https://localhost/api/oauth/resource/documentation","scopes_supported":["mcp:connect"]}

{"resource":"https://mcp.figma.com/mcp","authorization_servers":["https://api.figma.com"],"bearer_methods_supported":["header"],"scopes_supported":["mcp:connect"],"resource_name":"Figma MCP","resource_documentation":"https://developers.figma.com/docs/figma-mcp-server/"}u


{"issuer":"https://localhost","authorization_endpoint":"https://localhost/api/oauth/authorize","token_endpoint":"https://localhost/api/oauth/token","registration_endpoint":"https://localhost/api/oauth/register","response_types_supported":["code"],"code_challenge_methods_supported":["S256"],"grant_types_supported":["authorization_code","refresh_token"],"scopes_supported":["mcp_connect"],"require_state_parameter":true}

{"issuer":"https://api.figma.com","authorization_endpoint":"https://www.figma.com/oauth/mcp","token_endpoint":"https://api.figma.com/v1/oauth/token","grant_types_supported":["authorization_code","refresh_token"],"response_types_supported":["code"],"registration_endpoint":"https://api.figma.com/v1/oauth/mcp/register","code_challenge_methods_supported":["S256"],"scopes_supported":["mcp:connect"],"require_state_parameter":true}

symdeb avatar Dec 20 '25 12:12 symdeb

The issue with https: was caused by signed certificates . After lots of searching that now finally works with localhost. However, WARP still not does execute to direct to the authorization page. the situation is now the same for http and https

symdeb avatar Dec 20 '25 14:12 symdeb

I am guessing that WARP just simply rejects self signed certificates w/o giving any such hint. But even then, w.o TLS (plain http) it does not launch the consent/login page or browser, Perhaps WARP just rejects localhost totally for OAuth2. If that is the case, it would be nice to have that documented somewhere or have WARP give a clear error message ,than having to spending days to try and error figuring this out. Cursor and Dive give such explicit certificate error while Windsurf launches the login/consent page (so the server code is not the issue) but then fails for unknown reason. The whole OAuth2 implementation seems very inconsistent between different host/client apps. Only with MCP inspector self signed certificates the OAuth2 authorization code cycle ,with DCR, works fine.

symdeb avatar Dec 24 '25 15:12 symdeb