WorkIQ MCP CLI Initiates Redundant OAuth Flows Per Server Instead of Reusing Shared Token

Summary

The @microsoft/workiq MCP CLI initiates a separate OAuth PKCE browser flow for each MCP server at startup, even though all servers share the same AAD client ID and identical scope set. This results in 7–8 simultaneous browser prompts that must all be completed within a tight timeout window. If any prompt times out, orphaned .verifier files are left on disk and block future re-authentication flows for those servers.

Environment

Package: @microsoft/workiq (npm)

MCP Host: GitHub Copilot CLI (agency)

OS: Windows 11

Token cache path: %USERPROFILE%.copilot\mcp-oauth-config\

Observed date: 2026-03-12

Steps to Reproduce

Clear all cached tokens: Remove-Item "%USERPROFILE%.copilot\mcp-oauth-config*.tokens.json"

Start Copilot CLI with WorkIQ MCP servers configured

Observe 7–8 simultaneous browser OAuth prompts opening

If any prompt is not completed before timeout, the server remains unauthenticated

Expected Behavior

The CLI should detect that multiple MCP servers share the same AAD client ID (ea9ffc3e-8a23-4a7d-836d-234d7c7565c1) and scope set, and perform a single OAuth flow whose resulting token is reused across all servers.

Actual Behavior

​7–8 independent OAuth PKCE flows are initiated simultaneously. Inspection of the token cache confirms all tokens are redundant:

All token files have the same AAD audience: ea9ffc3e-8a23-4a7d-836d-234d7c7565c1

All token files have identical 33-scope sets (e.g., McpServers.Mail.All, McpServers.Teams.All, McpServers.Calendar.All, etc.)

​7 separate .tokens.json files are written for what is effectively 1 logical authentication

Secondary Bug: Orphaned Verifier Files Block Re-authentication

When a PKCE browser prompt times out before the user can complete it:

A .verifier file is written to %USERPROFILE%.copilot\mcp-oauth-config\ and never cleaned up

On next startup, the orphaned .verifier blocks a new OAuth flow from initiating cleanly for that server

The affected server silently fails — no error is surfaced to the user

Workaround:

Remove-Item "%USERPROFILE%.copilot\mcp-oauth-config*.tokens.json"
Remove-Item "%USERPROFILE%.copilot\mcp-oauth-config*.verifier"

Then restart the CLI and complete all browser prompts promptly.

Root Cause (Hypothesis)

The OAuth token cache key is likely derived per-server (e.g., using the server name or endpoint URL as part of the cache key), rather than deduplicating by (audience, scope_set). This causes N flows for N servers even when the token would be identical.

Proposed Fix

Token deduplication: Before initiating a new OAuth flow, check if an existing valid token in the cache satisfies the requested (audience, scopes) — if so, reuse it. This would reduce N browser prompts to 1.

Verifier cleanup: On startup, remove any .verifier files whose corresponding token is absent or expired, rather than treating them as in-progress flows.

User feedback: If an OAuth flow does time out, surface a clear error message indicating which server failed and provide the remediation command.

Impact

Poor first-run and re-authentication experience — users must complete 7–8 browser tabs simultaneously

Silent failure when any prompt times out — user has no indication which servers are broken

Non-obvious recovery path (clearing orphaned verifier files is not documented)

References

Public repo: https://github.com/microsoft/work-iq-mcp

NPM package: @microsoft/workiq

The issue names no source files or tests. Start by reproducing the multiple browser prompts with the WorkIQ MCP servers and inspect the token cache under %USERPROFILE%.copilot\mcp-oauth-config. Trace how cache entries are keyed and how .verifier files are handled after timeout; done means one flow is reused for matching audience and scopes, stale verifier files do not block re-authentication, and failures identify the affected server.