WorkIQ MCP server connects lazily per chat - cold OAuth reconnect races the first turn (+ intermittent HTTP 500)

[liamhowlett]

Bug report: WorkIQ MCP server connects lazily per chat — cold OAuth reconnect races the first turn (+ intermittent HTTP 500)

Repo: microsoft/work-iq · Plugin: workiq v2.0.0
Host: GitHub Copilot desktop app (hosting the Copilot CLI engine), Windows
Endpoint: https://workiq.svc.cloud.microsoft/mcp (http transport, public OAuth client)

Summary

On the first message of a newly opened chat, WorkIQ tool calls intermittently
fail and the assistant responds with a generic "I don't have access to
Teams/email/messages." Resending the same prompt a few seconds later succeeds.
The cause is that the workiq MCP server connects lazily per chat/session and
re-runs a full OAuth handshake (401 → token refresh → reconnect, ~3s) at the start
of each session, which races the model's first turn before the workiq-*
tools are registered. The endpoint also intermittently returns HTTP 500 during
that handshake.

This is not a token-caching problem: the OAuth token is already cached locally
with a valid refresh token (~1h access-token lifetime), so the reconnect is a
silent refresh — it's just not fast enough to beat the first turn.

Symptom

1. Open a new chat.
2. Immediately send an M365 prompt (e.g. "Check my most recent Teams message from
   Priya").
3. Assistant replies it has no access to Teams/email — because no workiq-* tool
   was in the toolset yet.
4. Resend the same prompt ~5–10s later → WorkIQ tools are now present and the call
   succeeds.

Root cause (from host logs)

• workiq is a plugin-contributed MCP server. On every new chat/session the
  client starts a fresh remote MCP client and re-runs OAuth before tools register.
• By contrast, standing/eager remote servers in the host (e.g. the Power BI
  remote MCP server) are connected once and stay warm, so they are available
  instantly in every fresh chat.
• The token is cached (refresh token present), so the ~3s is a silent
  refresh+reconnect, not an interactive login — but it still loses the race.

Log evidence (UTC; local = UTC+1)

15:54:34  Loaded MCP config from installed plugins: 2 server(s): PowerBIQuery, workiq
15:54:35  workiq requires authentication, initiating OAuth flow
15:54:37  Service initialized as client                     (~3s cold connect)
15:55:17  OAuth Error: ... HTTP 500 Internal Server Error    (endpoint flakiness)
16:03:04  Starting remote MCP client for workiq → AuthRequired
16:03:07  Service initialized                               (~3s again, new chat)

Repeated per-session reconnects observed at 15:47, 15:54, 15:55, 16:03.

Impact

• Intermittent, confusing first-message failures in new chats; to the user it
  looks like WorkIQ isn't installed or has no access, when it is installed and the
  token is valid.
• Users learn to "just resend," which is a poor first-run experience.

Requested fixes (in priority order)

1. Keep the WorkIQ connection warm / eager-connect at host startup, or reuse a
   shared connection across chats rather than reconnecting per session (parity with
   standing remote servers that are instantly available).
2. Gate the first model turn until plugin MCP tools finish registering, or
   surface an explicit "connecting" state, so the model doesn't answer before the
   tools exist.
3. Investigate/fix the intermittent HTTP 500 returned during OAuth/initialize
   against https://workiq.svc.cloud.microsoft/mcp.
4. Optionally allow registering WorkIQ as a standing remote server with an
   OAuth alias (parity with the Power BI remote server) for instant availability.

Workaround (today)

• Resend the prompt once, or wait ~5–10s after opening a chat before the first
  M365 prompt; the connection completes within a few seconds.
• Reuse a single warm chat for M365 lookups instead of opening a fresh chat each
  time.

Notes

• No secrets are included in this report. The OAuth client is a public client
  (client id ships in the plugin's .mcp.json); no access/refresh tokens are
  disclosed.