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

Start with the AgentHost/Copilot CLI MCP authentication provider and the Rust rmcp transport logs, then trace authorization-server metadata discovery for issuer URLs with path components. Compare the attempted URLs with the RFC 8414 path-aware sequence; done means discovery succeeds, sign-in opens the OAuth flow, and previously granted credentials work.