Cursor MCP DCR still omits application_type and uses a non-RFC-8252-compliant private redirect URI (3.14.27)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Follow-up to this thread from October 2025, acknowledged by a Cursor team member:

The issue persists in Cursor 3.14.27.

When connecting to an MCP server using OAuth Dynamic Client Registration (DCR), Cursor sends a registration payload that:

  1. Omits application_type. MCP Authorization 2026-07-28 requires MCP clients to specify it during DCR. Under OIDC, omission defaults to "web", which can conflict with native redirect URIs.

  2. Uses a non-RFC-8252-compliant private redirect URI. cursor://anysphere.cursor-mcp/oauth/callback uses a generic scheme with an authority component (://host/), instead of an authority-free, reverse-domain private scheme such as com.example.app:/path.

Authorization servers enforcing these policies reject DCR before login. This is reproduced with Better Auth and was reproduced with node-oidc-provider in the linked earlier report.

The RFC 8252 issue remains even after adding application_type: "native".

Observed error:

Connection failed: web clients require https redirect URIs on non-loopback hosts:
cursor://anysphere.cursor-mcp/oauth/callback

Payload observed (no secrets):

{
  "client_name": "Cursor",
  "redirect_uris": [
    "cursor://anysphere.cursor-mcp/oauth/callback",
    "https://www.cursor.com/agents/mcp/oauth/callback",
    "http://localhost:8787/callback"
  ],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Note: application_type is absent.

Steps to Reproduce

  1. Run an MCP authorization server with OAuth DCR, for example Better Auth @better-auth/oauth-provider 1.7.0-rc.4.
  2. Add the MCP server in Cursor via Settings → MCP → remote OAuth server.
  3. Cursor attempts DCR.
  4. Registration is rejected; login and consent are never reached.

Expected Behavior

Desktop DCR should send:

  • application_type: "native"
  • An RFC 8252-conformant, authority-free private redirect URI based on a domain Cursor controls, or a supported loopback redirect.

For example, the required private-URI syntax is:

com.example.app:/oauth/callback

This is only a syntax example; Cursor should select a reverse-domain scheme based on a domain it controls.

Registration should succeed without server-specific workarounds.

Impact

Immediate: MCP OAuth connections fail with authorization servers enforcing these redirect policies.

Security: No authentication bypass is demonstrated. However, the generic cursor:// scheme provides weaker collision resistance than the reverse-domain scheme required by RFC 8252.

Operating System

MacOS

Version Information

Version: 3.14.27
VS Code Extension API: 1.128.0
Commit: 047548b00c1a079373d74d00183f32510a4a41e0
Date: 2026-08-04T03:29:11.183Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. Your diagnosis is spot on, and it matches what we’re seeing on our side too. This is a known issue we’re tracking. The DCR payload still doesn’t include application_type and it registers a custom-scheme redirect URI, so spec-strict servers like Better Auth reject registration before login. The October thread never got closed with a fix, which is why the issue is still reproducible. I’ve passed both items to the team, the missing application_type and the RFC 8252 shape. I can’t share a timeline yet, but I’ll reply here when there’s an update.

Possible workaround, if your Better Auth server supports static or trusted OAuth clients. Configure a static client in mcp.json using auth.CLIENT_ID / CLIENT_SECRET / scopes so Cursor can skip DCR entirely, and on the server side only allow http://localhost:8787/callback. For DCR-only servers, there isn’t a client-side workaround right now.

Let me know if the static-client approach works for you, or if your server is strictly DCR-only. If it’s DCR-only, I’ll add that context for the team.

6

Hi :waving_hand: , thank you for confirming both issues.

My server relies on DCR for automatic onboarding. I added a narrow Cursor-specific compatibility patch while keeping PKCE, consent, and other MCP clients unaffected.

Static registration would require manual configuration for every user and place a client secret in a desktop configuration, where it cannot be treated as confidential. Once Cursor adds application_type: "native" and fixes the redirect URI, I’ll update or remove my patch accordingly.

Thanks again!

7

Hey, thanks for confirming. Got it, your server is DCR-only, and the static-client option doesn’t work for you. The secret in a desktop config can’t be treated as confidential, and it would also require manual setup for each user. That makes sense.

I shared this context with the team: a DCR-only scenario where a client-side workaround isn’t applicable, plus both issues: missing application_type and the redirect URI format per RFC 8252. I can’t share a timeline yet, but I’ll post here once there’s an update.

Thanks for temporarily covering this with your Cursor-specific patch while keeping PKCE and consent. Once Cursor adds application_type: "native" and a correct redirect URI, I’ll reply in the thread so you can remove the patch.