mcp-remote OAuth discovery fails against GitHub remote MCP server
When connecting punkpeye/mcp-remote to GitHub's remote MCP server at https://api.githubcopilot.com/mcp/ (opens external site), the OAuth discovery flow fails because the server's WWW-Authenticate challenge points
resource_metadatatohttps://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp, but the bundled TypeScript SDK rewrites that URL and drops the/mcppath. Was there a fix, and which mcp-remote version do I need?Originally asked on GitHub: https://github.com/punkpeye/mcp-remote/issues/116
6 answers
Fixed in mcp-remote v0.1.18 (released 2025-07-07).
The root cause was inside the bundled
@modelcontextprotocol/sdk, not your config: during OAuth discovery againsthttps://api.githubcopilot.com/mcp/, the server correctly sent aWWW-Authenticatechallenge withresource_metadatapointing tohttps://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp, but the SDK rewrote that URL tohttps://api.githubcopilot.com/.well-known/oauth-protected-resource, dropping the/mcppath so the flow failed.The maintainer fixed it by bumping the TypeScript SDK in mcp-remote PR #119 (opens external site) to a version that includes the upstream fix (typescript-sdk commit 354318f (opens external site)).
To resolve the issue:
- Update
punkpeye/mcp-remoteto v0.1.18 or later. - Re-run your connection to GitHub's remote MCP server. Users in the thread confirmed the
WWW-Authenticateresource metadata is now handled correctly.
Two notes from the thread:
- GitHub's remote MCP server does not support dynamic client registration, so you must register your own GitHub OAuth app to complete the flow.
- After the upgrade, one reporter got through the OAuth flow with their own app but hit a separate failure exchanging the authorization code for a token; that was still under investigation.
General advice: if you register your own GitHub OAuth app, keep the client secret out of shared config files.
Did this work for you?- Update
What a GitHub user tried on GitHub (Didn't work)
Reporter ran mcp-remote against GitHub's remote MCP server. OAuth discovery received the correct
WWW-Authenticateheader, but the bundled@modelcontextprotocol/sdkrewroteresource_metadatafrom.../oauth-protected-resource/mcpto.../oauth-protected-resource, breaking the flow.Source: https://github.com/punkpeye/mcp-remote/issues/116 (opens external site)
Did this work for you?What @geelen tried on GitHub (Worked)
Maintainer bumped the TypeScript SDK version in mcp-remote PR #119 and released v0.1.18 with the fix, asking users to test.
Source: https://github.com/punkpeye/mcp-remote/issues/116#issuecomment-3043226720 (opens external site)
Did this work for you?What @hearthsinger tried on GitHub (Worked)
User tested v0.1.18 against GitHub's remote MCP server and confirmed the
WWW-Authenticateheader is now used as expected.Source: https://github.com/punkpeye/mcp-remote/issues/116#issuecomment-3045594976 (opens external site)
Did this work for you?What @bpedman tried on GitHub (Partly worked)
Reporter confirmed the original URL-rewriting issue was fixed, but found GitHub doesn't support dynamic client registration. With their own OAuth app, the auth flow worked, but exchanging the auth code for a token still failed and needed further investigation.
Source: https://github.com/punkpeye/mcp-remote/issues/116#issuecomment-3054244249 (opens external site)
Did this work for you?What @hearthsinger tried on GitHub (Outcome unclear)
Another user reported being blocked by the same bug with any spec-compliant remote MCP server that appends a resource path to the
.well-knownroute, and requested the SDK version bump. No workaround was given.Source: https://github.com/punkpeye/mcp-remote/issues/116#issuecomment-3033425995 (opens external site)
Did this work for you?