[Bug] MCP OAuth client hardcodes prompt=consent, bypassing tenant-wide admin consent

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.

Captured authorize URL (Microsoft Entra / Agent 365 MCP server):

https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize
?response_type=code
&client_id=038aa3f3-b5b7-4ad0-a221-60f8c48e6f63
&code_challenge_method=S256
&redirect_uri=http://localhost:8080/callback
&scope=https://agent365.svc.cloud.microsoft/agents/tenants/<tenant>/servers/mcp_CalendarTools/.default openid profile offline_access
&prompt=consent
&resource=https://agent365.svc.cloud.microsoft/agents/tenants/<tenant>/servers/mcp_CalendarTools

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).

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.158
• Feedback ID: 762d4509-614d-4fef-846b-a4364c14b326

Errors

[]