Skip to content

Bug: OAuth DCR rejects Cursor's cursor:// redirect_uri (loopback-only enforcement blocks Cursor harness) #16

@denwx

Description

@denwx

Summary

Installing the OutSystems MCP server in Cursor (following the "Install - other AI assistants" path in the README) fails during OAuth Dynamic Client Registration. The server rejects Cursor's registered cursor://... callback URI, blocking the handshake before any tool listing happens. As a result, no outsystems tools surface in the harness.

A mcp-remote stdio bridge works around it (because the bridge opens its own http://localhost:PORT/callback), but native Cursor wiring per the README is non-functional.

Environment

  • Harness: Cursor (desktop, macOS), anysphere.cursor-mcp extension
  • Cursor MCP wiring: streamable HTTP transport (mcpServers.outsystems.url pointing at https://<tenant>/mcp), per the README "other AI assistants" recipe
  • Tenant: morpheus-qa.outsystemsrd.dev
  • Cursor MCP OAuth callback scheme: cursor://anysphere.cursor-mcp/oauth/callback

Steps to reproduce

  1. In Cursor, add to ~/.cursor/mcp.json:

    {
      "mcpServers": {
        "outsystems": {
          "url": "https://<tenant>/mcp"
        }
      }
    }
  2. Restart Cursor.

  3. Wait for MCP initialization. Observe that the outsystems server transitions initializing → error and no tools register.

Actual log output

From Cursor's per-server MCP log (exthost/anysphere.cursor-mcp/MCP user-outsystems.log):

[V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown
MCP OAuth provider initialized
MCP HTTP exchange completed
MCP HTTP exchange completed
MCP HTTP exchange completed
Registration lock acquired after stale cleanup — this provider will register
No stored client information found
MCP HTTP exchange completed
Transient error connecting to streamableHttp server: redirect_uri "cursor://anysphere.cursor-mcp/oauth/callback" rejected: redirect_uri must use scheme http for loopback
Connection failed: redirect_uri "cursor://anysphere.cursor-mcp/oauth/callback" rejected: redirect_uri must use scheme http for loopback
[V2 FSM] connection:connect_failure: conn=connecting,auth=unknown -> conn=failed,auth=unknown
CreateClient completed, connected: false, statusType: error

The DCR redirect_uri validation strictly enforces http:// for loopback addresses and rejects Cursor's custom URL scheme.

Expected

The OAuth authorization server accepts Cursor's cursor://anysphere.cursor-mcp/oauth/callback redirect URI during Dynamic Client Registration so that the install path from the README's "Install - other AI assistants" section works end-to-end in Cursor — matching how Claude Code and Kiro currently work.

OAuth 2.1 / RFC 8252 § 7.1 explicitly permits private-use URI scheme redirects for native apps (as an alternative to loopback HTTP and claimed https:// URIs). Custom schemes like cursor://, cursor-vscode://, vscode://, code-oss://, etc. are the standard pattern for desktop IDEs that don't want to spin up an ephemeral local HTTP server per OAuth flow.

Suggested fix

In the AS's redirect_uri validation, accept private-use URI schemes (anything with a .-containing reverse-DNS-style scheme name, per RFC 8252 § 7.1) in addition to http:// loopback. At minimum, allowlist the known scheme(s) used by harnesses the README claims to support best-effort: cursor://, plus whatever Continue / Cline / Codex CLI / Cursor use.

Workaround

Bridging through mcp-remote works:

{
  "mcpServers": {
    "outsystems": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://<tenant>/mcp"]
    }
  }
}

This shifts the OAuth flow into mcp-remote's local http://127.0.0.1:PORT/callback loopback, which the AS accepts. But it adds a runtime npm dependency and an extra hop, which the "other AI assistants" install instructions specifically try to avoid.

Impact

Any Cursor user following the README's documented install path hits this on first restart with no surfaced auth UI to recover (the failure happens during DCR, before the lazy authenticate tool would have a chance to run). The error is only visible by reading per-server MCP logs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions