`/mcp` interactive re-auth ignores `auth.redirectPort` and does not display the OAuth URL inline

[shajinzheng]

Version: copilot-cli v1.0.51

Summary

Two related issues in the /mcp slash command's interactive "Authenticate" action, both stemming from the same single callsite of authenticate() in the /mcp UI's React component:

1. auth.redirectPort is ignored (regression of v1.0.49 fix on this code path). Same MCP server config that pins port 19876 via auto-connect ends up on a random port via /mcp UI re-auth.
2. OAuth authorize URL is not surfaced inline. The TUI shows "Waiting for authorization in browser..." but never prints the URL. Users on remote dev environments (Codespaces, Coder workspaces) have no way to retrieve the URL without inspecting logs.

Both fix together with ~10 LOC in a single React component — the pattern already exists elsewhere in the codebase.

Repro

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

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

2. Delete any cached OAuth state for that server in ~/.copilot/mcp-oauth-config/.
3. Start a Copilot session. Don't touch /mcp. Auto-connect triggers OAuth.
4. Observe the printed authorize?...&redirect_uri=... URL → port 19876 ✓
5. Wipe OAuth state again. Restart Copilot.
6. Open /mcp, select the server, click Authenticate.
7. Observe the printed URL → random ephemeral port ✗
8. Also observe: the TUI shows "Waiting for authorization in browser..." but never displays the URL itself anywhere — only place it surfaces is via the env-configured $BROWSER invocation, which is hidden when stdout is captured by the TUI on remote/headless setups.

Expected

• /mcp UI re-auth honors auth.redirectPort, same as auto-connect already does.
• /mcp UI re-auth shows the URL inline in the TUI (the way the URL-elicitation component already does for MCP-server-requested URLs).

Actual

The /mcp UI's authenticate() callsite is missing both redirectPort and onAuthorizationUrl options:

// Current /mcp UI:
await provider.authenticate(serverUrl, {
  staticClientConfig,
  forceReauth,
  forceDeviceCode,
  signal,
  clientName,
  callbackSuccessMessage,
  onStatusChange,
  // ❌ MISSING: redirectPort
  // ❌ MISSING: skipBrowserOpen / onAuthorizationUrl
});

Both code paths that DO work correctly already exist in the codebase:

• MSt.getAuthProvider (auto-connect via mcp.oauth_required event handler): passes redirectPort: r.auth?.redirectPort.
• Foo.login (the AI-callable mcp.oauth.login tool): passes both redirectPort: u.auth?.redirectPort and skipBrowserOpen: true + onAuthorizationUrl: S => f(S).

Only the /mcp UI re-auth path is missing them.

Impact

Users on remote dev environments where only specific ports are forwarded to the laptop cannot complete OAuth via /mcp re-auth. Scenarios that hit this:

• Switching accounts
• Re-auth after token revocation
• Re-auth after refresh token expiry where the client wasn't proactively refreshed

Auto-connect at session start works (path #1 above). The bug is silent: first-time native config works, then the next time the user re-auths through /mcp, it suddenly fails. Hard to diagnose without reading the code.

Suggested fix

Add redirectPort + onAuthorizationUrl to the /mcp UI's authenticate() callsite, plus a small <Box> block in the same React component to render the URL when present. The "copy this URL" UI block is already implemented in the URL-elicitation component (the one that handles MCP-server-requested URL elicitations) — extract it into a shared <OAuthUrlPrompt> component and reuse it here.

Approximate diff:

   const [authUrl, setAuthUrl] = useState<string | undefined>();

   const authenticate = async (serverName, url, forceReauth = false, forceDeviceCode = false) => {
     // ...
     await provider.authenticate(url, {
       staticClientConfig,
       forceReauth,
       forceDeviceCode,
       signal: abortController.signal,
       clientName,
       callbackSuccessMessage,
       onStatusChange,
+      redirectPort: serverConfig?.auth?.redirectPort,
+      onAuthorizationUrl: (url) => setAuthUrl(url),
     });
   };

   return (
     <Box flexDirection="column" gap={1}>
       <Text bold color={statusColor}>{statusMessage}</Text>
+      {authUrl && (
+        <Box flexDirection="column" borderStyle="round" paddingX={1}>
+          <Text>If your browser didn't open, copy this URL manually:</Text>
+          <Text>{terminalHyperlink(chalk.underline(authUrl), authUrl)}</Text>
+        </Box>
+      )}
       {/* rest of UI */}
     </Box>
   );

Estimated total change: ~10 LOC, single file.

Workaround

Pre-register an OAuth client out-of-band (RFC 7591 dynamic client registration) with the desired redirect_uris, then seed ~/.copilot/mcp-oauth-config/<sha>.json with the resulting clientId + redirectUri. Copilot's OAuth provider parses the saved redirectUri's port and uses it via the existing fallback in authenticate():

let V = A ?? 0, F = V > 0;
if (!F && T?.redirectUri) try {
  V = parseInt(new URL(T.redirectUri).port, 10) || 0;
} catch {}

So pre-seeding the cache file effectively patches the /mcp UI bug without modifying Copilot CLI. Not great UX (relies on internal cache layout — filename hash is pbkdf2(serverUrl, "copilot-mcp-oauth-store-key-v1", 210000, 32, sha256)), but it works.

[reaworks-ops]

This is a good narrow support target because the failing path is already pinned to one /mcp UI auth callsite.

Concrete ReaWorks offer: $100 remote-dev OAuth acceptance packet / small PR support for this Copilot CLI MCP re-auth path. Buyer/maintainer sends the target branch plus one sanitized MCP config using auth.redirectPort and one Codespaces/Coder-style session where browser auto-open is unavailable.

Deliverable: either a tiny patch or reviewer-ready packet proving (1) /mcp interactive re-auth honors the configured redirect port, (2) the authorize URL is printed inline when browser launch is not usable, (3) cached OAuth cleanup/re-auth is replayable, and (4) logs exclude tokens/client secrets.

Acceptance proof: before/after terminal transcript + config fixture + redacted OAuth callback/readiness notes that a maintainer can replay without private credentials.