[BUG]: /mcp re-auth fails with EADDRINUSE on auth.redirectPort while eager-startup OAuth flow is still pending

[shajinzheng]

Describe the bug

When an HTTP MCP server is configured with auth.redirectPort and has no cached OAuth token, the CLI eagerly initiates the OAuth flow at session startup and binds the configured local callback port (e.g. 127.0.0.1:19878). The pending listener stays bound for ~5 minutes waiting for the browser callback.

If the user later runs /mcp → server → Authenticate during that window, the re-auth path tries to bind the same auth.redirectPort again and immediately fails with:

Authentication failed: MCPOAuthError: listen EADDRINUSE: address already in use 127.0.0.1:19878

The user has no way to recover the URL from the original eager flow either (it briefly appears on startup before the TUI renders over it, and is not surfaced anywhere in /mcp). The only workarounds are: wait ~5 minutes for the eager flow to time out, or remove the server from mcp-config.json and restart.

This appears to be a regression introduced by the fix for #3418 — that fix made /mcp re-auth honor auth.redirectPort (it previously used a random ephemeral port). Now both code paths fight over the same port within a single process.

Affected version

GitHub Copilot CLI 1.0.52-1

Steps to reproduce the behavior

1. Configure an HTTP MCP server with auth.redirectPort in ~/.copilot/mcp-config.json, with no cached token:

   {
     "mcpServers": {
       "linear": {
         "type": "http",
         "url": "https://mcp.linear.app/mcp",
         "auth": { "redirectPort": 19878 }
       }
     }
   }

2. Start Copilot CLI. Eager OAuth flow kicks off and binds 127.0.0.1:19878 (the URL is printed briefly before the TUI renders, easily missed on remote/headless sessions).
3. Within ~5 minutes, run /mcp → linear → Authenticate.
4. See: Authentication failed: MCPOAuthError: listen EADDRINUSE: address already in use 127.0.0.1:19878.

Verify via another shell that the eager listener is still alive throughout:

ss -tlnp | grep 127.0.0.1:19878
# LISTEN ... MainThread,pid=<copilot PID>,fd=XX

/restart and exit+resume do not help, because the new process re-runs the eager flow within ~200ms of startup and re-binds the same port (verified by polling ss -tlnp).

Expected behavior

Either of these alone would fix the bug; both together would be ideal:

1. Lazy auth on startup. Don't auto-initiate OAuth for servers requiring auth at session start. Only kick off the flow when the user explicitly authenticates via /mcp (or invokes a tool from that server). This guarantees the URL is born at the moment the user is looking at the TUI.
2. Detect-and-reuse pending flows. If /mcp → server → Authenticate is invoked while a flow is already pending for that server (listener already bound, URL+state already generated), surface the existing pending URL instead of trying to start a second listener. Something like:

   A pending authentication flow already exists for linear. Open this URL to complete it: https://...
   No second listener, no EADDRINUSE.

[shajinzheng]

Another potential fix: when the user explicitly initiates re-auth (via /mcp → Authenticate), the CLI should detect and close/abort any existing listener already bound to the configured auth.redirectPort before starting a new OAuth flow. Since it's the same process holding the port from the eager startup flow, it could simply tear down that pending listener (and invalidate its state/nonce), then bind fresh for the user-initiated flow. This avoids the EADDRINUSE entirely without needing to wait for the timeout or change the eager-auth behavior.