MCP OAuth: authorize request sends resource with a trailing slash that differs from the resource #5337

Describe the bug

For a remote HTTP MCP server configured with a bare-origin URL, the OAuth authorize request carries resource=https://mcp.example.com/ (trailing slash). The server's protected-resource metadata advertises "resource": "https://mcp.example.com" (no slash). The authorization server compares resource indicators exactly, so it rejects the request and the browser lands on its error page. The sign-in never starts.

The CLI seems to re-serialize the configured URL, where an empty path becomes /, instead of using the PRM resource value as published. I haven't confirmed the cause in the source.

Affected version

GitHub Copilot CLI 1.0.105 and 1.0.106-2 (prerelease), macOS arm64

Steps to reproduce the behavior

1. Configure ~/.copilot/mcp-config.json:

   {
     "mcpServers": {
       "example": {
         "type": "http",
         "url": "https://mcp.example.com",
         "oauthClientId": "<public-client-id>",
         "oauthPublicClient": true
       }
     }
   }

2. Run copilot, then /mcp and authenticate example.

Observed

• GET https://mcp.example.com/.well-known/oauth-protected-resource returns:

  {"resource":"https://mcp.example.com","authorization_servers":["https://auth.example.com"],"scopes_supported":["example:invoke","offline_access"],"bearer_methods_supported":["header"]}

• The authorize URL opened by the CLI:

  https://auth.example.com/connect/authorize?response_type=code&client_id=<public-client-id>&state=...&code_challenge=...&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3A<port>%2F&scope=example%3Ainvoke+offline_access&resource=https%3A%2F%2Fmcp.example.com%2F&prompt=consent+select_account
  

• The authorization server rejects it with: Invalid resource identifier "https://mcp.example.com/". It is either not found, not enabled, or does not support any of the requested scopes. The redirect_uri, scope and client all validate. Only the trailing slash differs.
• The CLI reports only MCP OAuth authorization failed.

Expected behavior

The resource parameter should be the PRM resource value exactly as published (RFC 9728 §3, RFC 8707 §2). Resource identifiers are absolute URIs compared as-is, so the CLI should not alter them. Other MCP clients, such as VS Code, send the PRM value without the slash and work against the same server.

Workaround

None in config. The per-server OAuth fields (oauthClientId, oauthPublicClient, oauthGrantType, oauthScopes) don't control resource.

Additional context

The CLI log shows a 401 challenge with resource_metadata and then MCP OAuth authorization failed. It does not log the authorize URL.