MCP OAuth always sends prompt=consent, forcing 'Approval required' loops in enterprise tenants that block user consent (even with admin consent already granted)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When Cursor initiates OAuth for a remote MCP server with static client credentials
(auth.CLIENT_ID in mcp.json), the authorize URL always includes prompt=consent.
Example (Microsoft Entra ID / Agent 365 MCP), authorize request includes parameters like:
response_type=code, client_id=…, redirect_uri=http://localhost:8787/callback,
scope=…, and prompt=consent
In tenants that disable user consent (common in enterprise/regulated orgs), this forces
an “Approval required” screen on every Connect attempt — even when:

  • Tenant admin consent has already been granted for the app
  • The exact same client ID + scopes work fine in other MCP clients (e.g. Claude Code,
    which does not send prompt=consent)
    Manually copying the authorize URL and removing prompt=consent before opening it in
    a browser allows sign-in to complete silently and the MCP server connects successfully —
    confirming this parameter is the root cause, not the Entra app config.
    Request: make prompt=consent optional/configurable in mcp.json’s auth block (e.g.
    auth.prompt or a boolean to suppress it), or drop it by default when the server
    reports admin consent is already satisfied.
    Environment:
  • Cursor Desktop, macOS
  • Remote MCP server, Streamable HTTP, static auth.CLIENT_ID
  • Microsoft Entra ID / Agent 365 Tools tenant with user consent disabled

Steps to Reproduce

  1. Register a public client app in Microsoft Entra ID with platform “Mobile and desktop
    applications” and redirect URI http://localhost:8787/callback
  2. Grant tenant admin consent for the required delegated API permissions/scopes on that app
  3. Add the MCP server to ~/.cursor/mcp.json using static OAuth credentials (auth.CLIENT_ID
    plus scopes)
  4. Reload Cursor, go to Settings, MCP, and click Connect on the server
  5. Observe the browser is redirected to Microsoft Entra ID’s OAuth2 v2.0 authorize endpoint
  6. Inspect the URL query parameters — it includes prompt=consent
  7. If the tenant has user consent disabled, this returns an “Approval required” screen
    requesting the user submit an admin approval request — every single time, regardless
    of prior admin consent
  8. As a manual test, copy the same authorize URL, remove only the prompt=consent parameter,
    and open the edited URL in the same browser tab/session
  9. Sign-in completes normally with no approval screen, and the MCP server connects
    successfully

Expected Behavior

Expected Behavior:

  • If the tenant admin has already granted consent for the app’s requested scopes, Cursor’s
    OAuth flow should not force an interactive consent screen on every Connect attempt
  • prompt=consent should either not be sent by default, or be configurable/optional in the
    mcp.json auth block (e.g. an auth.prompt field or boolean), so users/admins in enterprise
    tenants can suppress it
  • Other MCP clients (e.g. Claude Code) using the same Entra app, client ID, and scopes
    connect successfully without this forced prompt — indicating this is Cursor-specific
    behavior, not an issue with the Entra app or tenant configuration

Operating System

MacOS

Version Information

Version: 3.16.17
VS Code Extension API: 1.128.0
Commit: 6b2afae0257df2bb5e1835f15165dc2f0de056b0
Date: 2026-08-14T01:41:12.803Z
Layout: Agent Window
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.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Thanks for the detailed report. You’ve got this right: the authorize URL includes prompt=consent, and in a tenant with user consent disabled that sends people to the approval request screen every time, even where admin consent is already granted. Nothing in your app registration or tenant setup is causing it.

The parameter gets added whenever offline_access is in the requested scope set, and with Entra backed servers that scope usually comes from the server’s advertised metadata rather than your mcp.json, so it shows up even if you never asked for it. Editing the authorize URL by hand is the reliable path for now.

This is an issue we’re tracking, and we will post here with any updates.