Copilot CLI OAuth login fails — CLI doesn't bind to port declared in its own CIMD client-metadata.json

Describe the bug

When authenticating to an MCP server that uses CIMD (Client ID Metadata Document) OAuth, Copilot CLI fails with:

{"error":"invalid_request","error_description":"Redirect URI 'http://127.0.0.1:<random_port>/' does not match CIMD redirect_uris.","state":"..."}

Root cause: Copilot CLI's own published client metadata ( https://github.com/copilot/cli/client-metadata.json ) declares a single fixed redirect URI:

"redirect_uris": ["http://127.0.0.1:33418/"]

Per the CIMD/OAuth spec, the redirect_uri used in the  /authorize  request must exactly match this declared value (RFC 8252's "any loopback port" leniency only applies when no port is specified — here one is).

However, Copilot CLI does not bind its local OAuth callback listener to port 33418 — it uses a different, seemingly random port instead (observed: 63450, then 61566), even when port 33418 is confirmed free/unused on the machine. This causes every login attempt against CIMD-based OAuth servers to fail.

Affected version

Copilot CLI v1.0.83, Windows

Steps to reproduce the behavior

1. Confirm port 33418 is free ( Get-NetTCPConnection -LocalPort 33418  returns nothing).
2. Attempt login to an MCP server using CIMD OAuth (client_id = a metadata document URL).
3. Copilot CLI opens a callback listener on a different port than 33418.
4. Server rejects with  invalid_request  / redirect_uri mismatch.

Expected behavior

Copilot CLI should bind its OAuth loopback listener to the exact port(s) declared in its own  client-metadata.json  (33418), consistent with CIMD requirements.

Additional context

No response

Comienza siguiendo el flujo de OAuth desde la solicitud /authorize hasta el listener de callback de loopback local y, después, compara el puerto seleccionado con el valor de redirect_uris en el client-metadata.json publicado. Reproduce el problema con el puerto 33418 libre y un servidor CIMD MCP; se considera terminado cuando el listener y la solicitud usan la URI declarada y el inicio de sesión deja de devolver invalid_request.