You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug Description
Claude Code's built-in MCP OAuth client (authorization code + PKCE) appends prompt=consent to every authorization request. This forces the IdP consent screen on every single authentication, even when tenant-wide
admin consent has already been granted.
The scope is .default, which with admin consent should authenticate silently — but prompt=consent overrides that by design, so admin consent can never suppress the prompt. Every reconnect requires manually clicking
through consent again, across each MCP server (Calendar, Mail, Teams, SharePoint, etc.) individually.
Impact: Significant friction for enterprise/M365 SSO scenarios. Admin consent is the standard mechanism orgs use to pre-approve apps; hardcoding prompt=consent defeats it.
Requested fix: Don't send prompt=consent by default — omit it, or use prompt=select_account — and/or expose the prompt parameter as a configurable field in the MCP server OAuth config so it can be overridden.
Environment: Claude Code CLI, macOS, remote HTTP MCP servers using OAuth (Microsoft Agent 365 / WorkIQ).
Thank you for taking the time to report this. We're currently triaging open MCP issues, and this one is being closed in favor of tracking it in #49722, which covers the same root cause — the hardcoded prompt=consent on the remote-HTTP MCP OAuth authorize URL when Entra is the IdP. The admin-consent friction on reconnect and the user-consent-disabled block are two faces of the same parameter. Please follow that issue for updates and feel free to add any additional context there.
Hi @ChrisMcMillon, the hardcoded prompt=consent is a real enterprise blocker — it forces an unnecessary consent screen on every auth even when the organization has already granted tenant-wide consent.
The root cause is that the OAuth client is treating every authorization request as a new consent event instead of checking whether consent has already been granted at the tenant level. The fix is to make prompt=consent conditional: only add it when the authorization server indicates that fresh consent is needed (via a consent_required error or similar).
For enterprise deployments, the OAuth client should also support a configurable prompt parameter so organizations can set it to 'select_account' or 'none' based on their consent policies. Is the team at framedata planning to patch this or wait for the upstream fix in #49722?
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
Activity
localden commentedon Jun 1, 2026
Thank you for taking the time to report this. We're currently triaging open MCP issues, and this one is being closed in favor of tracking it in #49722, which covers the same root cause — the hardcoded
prompt=consenton the remote-HTTP MCP OAuth authorize URL when Entra is the IdP. The admin-consent friction on reconnect and the user-consent-disabled block are two faces of the same parameter. Please follow that issue for updates and feel free to add any additional context there.Marsssssssssssdsss commentedon Jun 2, 2026
Hi @ChrisMcMillon, the hardcoded prompt=consent is a real enterprise blocker — it forces an unnecessary consent screen on every auth even when the organization has already granted tenant-wide consent.
The root cause is that the OAuth client is treating every authorization request as a new consent event instead of checking whether consent has already been granted at the tenant level. The fix is to make prompt=consent conditional: only add it when the authorization server indicates that fresh consent is needed (via a consent_required error or similar).
For enterprise deployments, the OAuth client should also support a configurable prompt parameter so organizations can set it to 'select_account' or 'none' based on their consent policies. Is the team at framedata planning to patch this or wait for the upstream fix in #49722?
github-actions commentedon Aug 4, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.