AgentHost MCP client fails OAuth metadata discovery for authorization-server issuer URLs with a path component

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

1. 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).
2. 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).
3. In the standard Copilot Chat window, the server connects and authenticates successfully.
4. 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

先从 AgentHost/Copilot CLI MCP 身份验证提供程序和 Rust rmcp 传输日志入手，然后跟踪针对包含路径组件的 issuer URLs 的授权服务器元数据发现过程。将尝试过的 URL 与 RFC 8414 中支持路径的序列进行比较；发现成功、登录打开 OAuth 流程且之前授予的凭据可以正常使用，即表示完成。