MCP OAuth DCR still uses custom-scheme callback on 3.13.25 — breaks standards-compliant providers

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor IDE still performs MCP OAuth Dynamic Client Registration with a custom-scheme redirect URI (the anysphere.cursor-mcp oauth callback).

Standards-compliant OAuth authorization servers / DCR implementations that only allow http or https redirect URIs reject this. That blocks remote MCP servers that work fine with Claude Code (which uses a first-party https callback).

Concrete failure against KnowDrive MCP on dev.knowdrive.ai:

redirect_uri scheme not allowed (cursor custom-scheme callback)

The same provider accepts RFC 8252 localhost loopback callback on port 8787 via DCR. Cursor staff previously said MCP OAuth moved to loopback on the mcp_process surface, but this install on Cursor 3.13.25 still uses the old custom-scheme / exthost path.

Custom-scheme redirects are an unacceptable default for MCP OAuth DCR. Please fully retire the custom-scheme callback for DCR and use RFC 8252 loopback (127.0.0.1 / localhost) and/or a first-party https callback on all installs.

Steps to Reproduce

  1. Add a remote Streamable HTTP MCP server that requires OAuth + DCR (example: KnowDrive MCP on dev.knowdrive.ai).
  2. In Cursor Settings → MCP, click Connect / authenticate for that server.
  3. Observe DCR / authorize request uses the cursor custom-scheme oauth/callback redirect URI.
  4. Provider rejects registration/auth with “redirect_uri scheme not allowed”.
  5. Confirm the same provider accepts the RFC 8252 loopback callback localhost:8787/callback in DCR.

Expected Behavior

MCP OAuth DCR should never register or send custom-scheme redirect URIs.

All Cursor installs should use industry-standard callbacks:

  • RFC 8252 loopback on 127.0.0.1 or localhost
  • and/or a first-party https callback (as Claude Code does)

The gradual leftover exthost custom-scheme path should be removed.

Operating System

MacOS

Version Information

Version: 3.13.25
OS: macOS (darwin 23.6.0)
MCP server: KnowDrive on dev.knowdrive.ai
Log evidence (mcp-server-user-knowdrive.log):
Transient error connecting to streamableHttp server: redirect_uri scheme not allowed (cursor custom-scheme oauth callback)

Additional Information

Related prior staff confirmation that Cursor moved MCP OAuth to localhost loopback because many providers reject the cursor custom scheme: forum topic “OAuth redirect URI changed from cursor to http localhost for Streamable HTTP MCP”.

This report is that 3.13.25 is still on the old custom-scheme path, so standards-compliant MCP providers remain broken.

Comparison: Claude Code connects to the same KnowDrive MCP endpoint successfully using https OAuth callbacks.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Hey there,

This is an issue we’re tracking. Same class as OAuth redirect URI changed from cursor:// to http://localhost for Streamable HTTP MCP.

Workaround if KnowDrive lets you create a static OAuth client: put its credentials in mcp.json so Cursor skips DCR:

"auth": {
"CLIENT_ID": "...",
"CLIENT_SECRET": "...",
"scopes": ["..."]
}

Allowlist only http://localhost:8787/callback on that client. Details: Static OAuth for remote servers.

If KnowDrive is DCR-only (no manual client), there isn’t a clean client-side fix yet - reducing what we register during DCR is on us. I’ll post here when there’s an update.