MCP Server OAuth flow scope error has regressed on GitLab.com

Summary

The MCP Server OAuth flow on GitLab.com is again failing with "The requested scope is invalid, unknown, or malformed" when initiating a connection from third-party MCP clients (e.g., Claude Desktop, Claude managed agents). This is a regression of the behavior originally reported and fixed in #585699 (closed).

Multiple users have confirmed the recurrence in comments on #585699 (closed) (see comment by @EdLuno, comment by @rburchell-edmundsgovtech, comment by @truckstop-bjmyers), and a support ticket has been filed confirming the same behavior. This follow-up issue was requested by @dnsmichi in this comment since #585699 (closed) targets milestone 18.9 and is locked into a changelog.

Steps to reproduce

1. Create a GitLab group-level OAuth application with:
   • Redirect URI: the callback URL provided by the MCP client (e.g., https://claude.ai/api/mcp/auth_callback)
   • Scopes: api, ai_features (or any combination of standard scopes)
   • Confidential: No (non-confidential)
2. Configure the MCP client (e.g., Claude Desktop) with:
   • MCP Server URL: https://gitlab.com/api/v4/mcp
   • OAuth Client ID: the Application ID from the GitLab application
3. Initiate the OAuth connection flow from the MCP client
4. Observe the error on the GitLab authorization page

Current behavior

The browser displays the error:

An error has occurred — The requested scope is invalid, unknown, or malformed.

The OAuth authorization flow cannot be completed. The integration is completely blocked.

As noted by @EdLuno in #585699 (closed), the scopes being requested that do not appear as checkboxes in the GitLab OAuth application UI (Settings → Applications) include: mcp, mcp_orbit, ai_workflows, self_rotate, user:*. Since these scopes cannot be granted in the UI, and GitLab's auth server rejects them outright, the flow fails.

Expected behavior

The MCP OAuth flow should complete successfully, as it did after the original fix in #585699 (closed) was deployed (confirmed working by @jozef8 on 2026-01-27). The MCP OAuth application should handle scope negotiation gracefully, either:

• Accepting the mcp scope (as was fixed in !219070 (merged) and !219146 (merged)), or
• Gracefully falling back when unrecognized scopes are requested

Environment

• GitLab.com (SaaS)
• MCP endpoint: https://gitlab.com/api/v4/mcp
• Affected clients: Claude Desktop, Claude managed agents (platform.claude.ai), and likely other MCP clients using Dynamic Client Registration

Relevant references

• Original issue (closed): #585699 (closed)
• Upstream client bug: anthropics/claude-code#55954 — MCP client requests every scope from the authorization server's scopes_supported instead of the resource's; independently confirms this is client-side
• Original fix MRs: !219070 (merged) (Force MCP scope to MCP API endpoint), !219146 (merged) (Add scopes_supported to Protected Resource Metadata)
• Parent epic: 🐞 GitLab MCP Server bugs
• Related issue: #602891 (closed) (/oauth/register returns plain-text body on 429)

Possible causes

This may be related to changes in how MCP clients negotiate scopes since the original fix. The original fix ensured:

1. Dynamic MCP applications are created with only the mcp scope
2. The Protected Resource Metadata (/.well-known/oauth-protected-resource) exposes scopes_supported: ["mcp"]

However, some MCP clients may be falling back to the Authorization Server Metadata (/.well-known/oauth-authorization-server) which lists all 24+ supported scopes, or the clients may be requesting scopes (mcp_orbit, ai_workflows, self_rotate, user:*) that are not recognized by GitLab's OAuth application UI.