Describe the bug
The Copilot CLI "AgentHost" chat surface in VS Code cannot authenticate to OAuth-protected MCP servers whose authorization-server issuer URL includes a path segment (e.g. mcp.example.com/oauth rather than just mcp.example.com). Discovery fails before any consent/sign-in prompt can be shown, so clicking "sign in" for the server has no visible effect. The standard VS Code GitHub Copilot Chat MCP client, connecting to the identical server config, succeeds without issue.
Affected version
1.0.81-0
Steps to reproduce the behavior
- Configure a remote HTTP MCP server whose OAuth-protected-resource metadata points to an authorization server issuer URL with a non-root path, e.g. issuer
mcp.example.com/oauth (rather than a bare domain).
- Add the identical server config to both a standard Copilot Chat MCP config (VS Code's
mcp.json) and an AgentHost/Copilot CLI MCP config (~/.copilot/mcp-config.json).
- In the standard Copilot Chat window, the server connects and authenticates successfully.
- In the AgentHost/Copilot CLI session, the server never connects; attempting to sign in via the UI produces no browser/consent prompt at all.
Expected behavior
Clicking sign-in launches an OAuth consent flow, or the connection succeeds using previously-granted credentials.
Additional context
Actual
AgentHost repeatedly logs, including at the exact moment of clicking sign-in:
[AgentHost] Failed to create MCP auth provider for mcp.example.com/oauth
Failed to fetch authorization server metadata from all attempted URLs
The Copilot CLI backend logs show the underlying Rust rmcp transport failing with a 401 invalid_token/Authentication required OAuth challenge, while the working Copilot Chat client's logs show the correct RFC 8414 path-aware discovery sequence succeeding (.well-known/oauth-authorization-server inserted before the issuer's path).
Suspected root cause
The AgentHost/Copilot CLI MCP client's authorization-server metadata discovery doesn't correctly insert /.well-known/oauth-authorization-server/ before the issuer's path segment (RFC 8414 §3.1) when the issuer URL has a path component. It likely only tries a root-relative or path-appended well-known URL, so all discovery attempts fail and no auth/consent flow is ever created.
Also affected
The same 401/discovery-failure pattern was observed for other OAuth-protected MCP servers with path-based issuer URLs in the same session, suggesting this is general rather than vendor-specific.
Environment
- macOS
- Affected surface: Copilot CLI / "AgentHost" chat sessions inside VS Code (session type
copilotcli)
- Working comparison surface: standard GitHub Copilot Chat panel, same VS Code install, same MCP server config
Describe the bug
The Copilot CLI "AgentHost" chat surface in VS Code cannot authenticate to OAuth-protected MCP servers whose authorization-server issuer URL includes a path segment (e.g.
mcp.example.com/oauthrather than justmcp.example.com). Discovery fails before any consent/sign-in prompt can be shown, so clicking "sign in" for the server has no visible effect. The standard VS Code GitHub Copilot Chat MCP client, connecting to the identical server config, succeeds without issue.Affected version
1.0.81-0
Steps to reproduce the behavior
mcp.example.com/oauth(rather than a bare domain).mcp.json) and an AgentHost/Copilot CLI MCP config (~/.copilot/mcp-config.json).Expected behavior
Clicking sign-in launches an OAuth consent flow, or the connection succeeds using previously-granted credentials.
Additional context
Actual
AgentHost repeatedly logs, including at the exact moment of clicking sign-in:
The Copilot CLI backend logs show the underlying Rust
rmcptransport failing with a 401invalid_token/Authentication requiredOAuth challenge, while the working Copilot Chat client's logs show the correct RFC 8414 path-aware discovery sequence succeeding (.well-known/oauth-authorization-serverinserted before the issuer's path).Suspected root cause
The AgentHost/Copilot CLI MCP client's authorization-server metadata discovery doesn't correctly insert
/.well-known/oauth-authorization-server/before the issuer's path segment (RFC 8414 §3.1) when the issuer URL has a path component. It likely only tries a root-relative or path-appended well-known URL, so all discovery attempts fail and no auth/consent flow is ever created.Also affected
The same 401/discovery-failure pattern was observed for other OAuth-protected MCP servers with path-based issuer URLs in the same session, suggesting this is general rather than vendor-specific.
Environment
copilotcli)