Description
OAuth-protected MCP servers (Work IQ Calendar/Mail/Teams/OneDrive/Word + custom SkylineApi) show green/connected in the MCP servers settings page but consistently fail to provide tools in any session.
Reproduction steps
- Configure multiple OAuth-protected HTTP MCP servers in
~/.copilot/mcp-config.json (e.g. Work IQ servers at agent365.svc.cloud.microsoft and a custom Azure-hosted server)
- Start the Copilot app — MCP servers settings page shows all servers with green status indicators
- Open any new session (chat or project session)
- Try to use tools from any OAuth-protected server → tools are not available
What the logs show
From process-*.log during session creation:
Phase 1: Initial connection fails with AuthRequired
Server SkylineApi requires authentication, initiating OAuth flow
OAuth authentication required for SkylineApi
Phase 2: OAuth request sent to wrong handler
[extension:...\task-housekeeping\extension.mjs] Received MCP OAuth request without a registered MCP auth handler.
OAuth handler did not provide credentials for SkylineApi (cancelled); marking as needs-auth
OAuth required for SkylineApi with no cached tokens; marking as needs-auth
The OAuth request is being routed to an unrelated local extension (task-housekeeping) instead of the app's built-in OAuth handler. The extension correctly reports it has no MCP auth handler registered, but the app interprets this as a cancellation and permanently marks the server as needs-auth.
Phase 3: Work IQ servers eventually connect after retries (~10-30s)
MCP client for Work IQ Calendar connected, took 3022ms
MCP client for Work IQ Teams connected, took 718ms
MCP client for Work IQ Word connected, took 587ms
MCP client for Work IQ Mail connected, took 690ms
Phase 4: All connections drop ~90 seconds later
MCP connection for Work IQ OneDrive closed
MCP connection for Work IQ Mail closed
MCP connection for Work IQ Word closed
MCP connection for Work IQ Teams closed
MCP connection for Work IQ Calendar closed
Phase 5 (SkylineApi): Never reconnects
OAuth required for SkylineApi with no cached tokens; marking as needs-auth
The SkylineApi uses Azure AD OAuth (api://eadfb142-206f-4a1b-a917-a719539433a0/user_impersonation). The app detects the AuthRequired response from the /.well-known/oauth-protected-resource endpoint but cannot complete the OAuth flow because the auth request is routed to the wrong handler.
Expected behavior
- The app's built-in OAuth handler should handle MCP OAuth requests, not route them to unrelated extensions
- OAuth tokens should be cached and refreshed automatically
- Once connected, MCP connections should remain open for the session lifetime (or reconnect automatically)
- The settings page green indicator should reflect actual runtime connectivity, not just config validity
Environment
- App version: 1.0.19 (
com.github.githubapp)
- CLI version: 1.0.69
- OS: Windows 11
- MCP servers affected: All OAuth-protected HTTP servers (5× Work IQ at
agent365.svc.cloud.microsoft + 1× custom Azure Container Apps server)
- MCP servers working: Non-OAuth servers (
microsoft-learn, github-mcp-server, markitdown local) all connect fine
MCP config (sanitized)
{
"mcpServers": {
"SkylineApi": {
"type": "http",
"url": "https://<custom-azure-container-app>/mcp",
"timeout": 28800000
},
"Work IQ Calendar": {
"type": "http",
"url": "https://agent365.svc.cloud.microsoft/agents/tenants/<tenant-id>/servers/mcp_CalendarTools",
"timeout": 14400000
}
}
}
(Same pattern for Work IQ Mail, Teams, OneDrive, Word)
Description
OAuth-protected MCP servers (Work IQ Calendar/Mail/Teams/OneDrive/Word + custom SkylineApi) show green/connected in the MCP servers settings page but consistently fail to provide tools in any session.
Reproduction steps
~/.copilot/mcp-config.json(e.g. Work IQ servers atagent365.svc.cloud.microsoftand a custom Azure-hosted server)What the logs show
From
process-*.logduring session creation:Phase 1: Initial connection fails with AuthRequired
Phase 2: OAuth request sent to wrong handler
The OAuth request is being routed to an unrelated local extension (task-housekeeping) instead of the app's built-in OAuth handler. The extension correctly reports it has no MCP auth handler registered, but the app interprets this as a cancellation and permanently marks the server as
needs-auth.Phase 3: Work IQ servers eventually connect after retries (~10-30s)
Phase 4: All connections drop ~90 seconds later
Phase 5 (SkylineApi): Never reconnects
The SkylineApi uses Azure AD OAuth (
api://eadfb142-206f-4a1b-a917-a719539433a0/user_impersonation). The app detects theAuthRequiredresponse from the/.well-known/oauth-protected-resourceendpoint but cannot complete the OAuth flow because the auth request is routed to the wrong handler.Expected behavior
Environment
com.github.githubapp)agent365.svc.cloud.microsoft+ 1× custom Azure Container Apps server)microsoft-learn,github-mcp-server,markitdownlocal) all connect fineMCP config (sanitized)
{ "mcpServers": { "SkylineApi": { "type": "http", "url": "https://<custom-azure-container-app>/mcp", "timeout": 28800000 }, "Work IQ Calendar": { "type": "http", "url": "https://agent365.svc.cloud.microsoft/agents/tenants/<tenant-id>/servers/mcp_CalendarTools", "timeout": 14400000 } } }(Same pattern for Work IQ Mail, Teams, OneDrive, Word)