MCP OAuth callback changed to http://localhost:8787/callback and authentication still fails

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

OAuth authentication for a remote MCP server fails after Cursor generates the following callback URL:

http://localhost:8787/callback

This callback URL has already been registered exactly as generated in the OAuth client configuration. However, the authorization page still displays a redirect URI warning, and the MCP connection cannot be completed.

Some Cursor installations still generate the previous callback:

cursor://anysphere.cursor-mcp/oauth/callback

The callback selected by Cursor appears to vary between installations, even when connecting to the same remote MCP server.

Steps to Reproduce

Configure a remote HTTP MCP server in Cursor.
Open the MCP settings.
Click Connect to start the OAuth authentication.
Cursor opens the authorization page in the browser.
Inspect the redirect_uri generated by Cursor.
Cursor sends the localhost callback on the affected installation.
Confirm that the same localhost callback is already registered in the OAuth client configuration.
Continue the authentication.
The authorization page displays a redirect URI warning, and authentication cannot be completed.

Expected Behavior

Cursor should successfully complete the OAuth authentication when the callback URL generated by Cursor is registered exactly in the OAuth client configuration.

The callback behavior should also be consistent between Cursor installations connecting to the same remote MCP server.

Alternatively, Cursor should provide a supported setting to select whether the MCP OAuth flow uses the localhost callback or the previous custom protocol callback.

Operating System

Windows 10/11

Version Information

IDE: Version: 3.11.19

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey there! This is expected behavior, not a regression, and it’s fixable on your side. We recently switched MCP OAuth in the desktop IDE to http://localhost:8787/callback, though some installs still fall back to the old cursor:// one, which is why it looks inconsistent.

Fix: in your OAuth client, allowlist both of these and keep both registered:
http://localhost:8787/callback
cursor://anysphere.cursor-mcp/oauth/callback

That way whichever callback a given install sends will match. There’s no mcp.json field or setting to pick the callback, so registering both is the way to go. See Static OAuth for remote servers.

If the warning persists after adding both, send the exact redirect_uri from Output → MCP: <your server> logs plus your provider name and I’ll dig in.