Windows: Entra broker token cache stays 0 bytes after MCP sign-in, so every new process re-prompts #5236

Activity

1. bha7esh

   added the

   Bug

   issue type on Oct 22, 2026
2. bha7esh

   added

   triage

   on Oct 22, 2026
3. copilot-cli-bot

   added

   area:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registryMCP server configuration, discovery, connectivity, OAuth, policy, and registry

   area:platform-windowsWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows TerminalWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows Terminal

   and removed

   triage

   on Oct 23, 2026
4. jlac0716 commented on Oct 25, 2026

   

   jlac0716

   on Oct 25, 2026

   More actions

   Additional observations from a Windows x64 startup on 10/25, using PowerShell, Copilot CLI 1.0.103 and Agency 2026.10.22.3:

   • Repeated Microsoft account windows occur when starting new sessions with EngHub and IcM configured as HTTP MCP servers.
   • A metadata-only check found the Entra broker token-cache file at 0 bytes and the account record at 1,974 bytes. The empty cache file's last-write date is 10/7; the account record was updated on 10/25. I have not established whether this startup attempted to rewrite the cache. No credential-file contents were inspected.
   • The same startup also logged an IcM authentication failure at 18:12:33 UTC: A Microsoft sign-in is already in progress. Complete or cancel it before trying again.

   The last observation matches the concurrent-sign-in message in #5250: broker sign-ins rejected instead of queued, but on Windows rather than macOS. It does not reproduce that report's separate rejected-cached-token scenario.

   These observations suggest checking token persistence and concurrent sign-in handling separately; they do not prove a common root cause. Scope-binding configuration on this machine is non-default, so this is not a clean-default-settings reproduction. No cache deletion, auth-setting changes or runtime patches were made for this report.
5. peterbax117 commented on Oct 26, 2026

   

   peterbax117

   on Oct 26, 2026

   More actions

   Same on Windows x64, CLI 1.0.103 (pinned). entra-broker-cache\*.bin both 0 bytes (last written 10/8, 10/9); entra-broker-accounts\*.bin rewritten each session. Log comparison over 5 days: 5/5 sessions on 1.0.103 hit "A Microsoft sign-in is already in progress" (53 total, across powerbi, icm, workiq-word, workiq-mail, EngHub); 0 of 4 sessions on 1.0.86/1.0.95. Result is 2+ account pickers per session, plus mid-session pickers (icm). Also matches #5250's concurrency failure on Windows.
6. peterbax117 commented on Oct 29, 2026

   

   peterbax117

   on Oct 29, 2026

   More actions

   Data point on 1.0.105, Windows x64 with WAM (2 interactive launches, 02:07 and 02:08 UTC on 10/29). The behavior changed from repeated account pickers to a startup hang:

   • UI reports requires authentication for workiq-calendar, powerbi-remote, workiq-word, icm, workiq-mail and engms, then the status bar stays at Loading: ... 4 MCP servers - still waiting indefinitely.
   • Log shows [entra-broker] installed the MSAL broker as the host token source, then rmcp::transport::worker worker quit with fatal: Transport channel closed, when Client(OAuthChallenge ...) for the agent365 and icm-mcp-prod endpoints within 3 seconds of start.
   • After mcp incremental reconcile: (re)starting server for workiq-teams and workiq at +1.4 s, no further MCP engine events are logged; the remaining servers never leave pending.
   • No sign-in prompt appears, so there is nothing to complete. Same machine as my earlier comment (broker cache files still 0 bytes).
7. immuzz commented on Nov 4, 2026

   

   immuzz

   on Nov 4, 2026

   More actions

   Same on Windows 11 ARM64, CLI 1.0.105, with the WorkIQ plugin (workiq@copilot-plugins 2.0.2, https://workiq.svc.cloud.microsoft/mcp, client id ba081686-…). This is the biggest daily annoyance I have with the CLI.

   Metadata only (no file contents read):

   • ~\.copilot\entra-broker-cache\ba081686-5d24-4bc6-a0d6-d034ecffed87.bin: 0 bytes, last written 2026-10-07.
   • ~\.copilot\entra-broker-accounts\ba081686-….bin: 1,590 bytes, last written 2026-11-04 02:51 UTC (the latest session start).
   • ~\.copilot\mcp-oauth-config\ has 672 *.tokens.json files (85 written on 2026-11-01 alone). Restoring 7 sessions after a reboot wrote 7 new files within ~20 seconds; the ones I checked held the same access token (same iat). Each file's expiresAt is write time + 5 min, while the JWT exp is ~75 min after iat. So a cached token is treated as stale after 5 minutes, and with the broker cache empty every new process falls back to interactive sign-in.

   Logs, 2026-11-03: 28 separate CLI processes logged this pattern for workiq:

   [WARNING] [rust:mcp_engine::agent_host] HTTP 401 challenge (WWW-Authenticate: … client_id="fdcc1f02-…", resource_metadata="https://workiq.svc.cloud.microsoft/.well-known/oauth-protected-resource…")
   [WARNING] [rust:mcp_client::session_authorizer] MCP OAuth authorization failed; reporting the server as needing auth {"server":"workiq","error":"Browser-based OAuth required for https://workiq.svc.cloud.microsoft/mcp"}
   

   Mid-session it shows up as tool failures, which stop autopilot tasks halfway:

   • Re-authentication required for MCP server "workiq". Sign in again through your MCP client's authentication settings. (3× in one session, 12:23–12:45 UTC)
   • MCP tool catalog changed before tool "workiq-retrieve" could be invoked: Failed to verify cached MCP tools: MCP OAuth challenge required (HTTP 401)

   I filed the server-side half (WorkIQ returning 500 AuthenticationRequired inside tool results instead of a 401 challenge) at microsoft/work-iq: microsoft/work-iq#241
8. immuzz commented on Nov 4, 2026

   

   immuzz

   on Nov 4, 2026

   More actions

   Workaround that works for me (Windows 11 ARM64, WorkIQ): copilot update prerelease → 1.0.106-8. Its notes include "Reuse valid saved MCP OAuth credentials for anonymous connections and initial challenges without requiring another sign-in" (1.0.106-3).

   After updating, 3 of 3 fresh headless runs (copilot -p … workiq-fetch /me) returned data with no sign-in prompt and no Browser-based OAuth required / MCP OAuth authorization failed log lines. On 1.0.105 the same kind of run logged those lines 28 times on 2026-11-03.

   The broker cache file is still 0 bytes, so the underlying persistence bug in this issue still stands; 1.0.106 just reuses the saved token instead of re-prompting.
9. peterbax117 commented on Nov 6, 2026

   

   peterbax117

   on Nov 6, 2026

   More actions

   Confirmed fixed on Windows x64 with 1.0.107.

   • Interactive session: zero sign-in prompts; workiq-calendar, workiq-teams and icm all connected.
   • A new headless copilot -p process afterward: workiq-calendar, workiq-teams, icm and engms all OK with no prompt.
   • Note: a headless run before any interactive 1.0.107 session failed with Entra broker could not silently acquire a token for every Entra server. After one interactive session, headless works.
   • No startup hang on 1.0.107 (1.0.105 hung for me).
   • entra-broker-cache\*.bin is still 0 bytes, so the saved sign-in is coming from somewhere else. That has no practical impact.

   Thanks for the fix.
10. doomslayer2k commented on Nov 12, 2026

    

    doomslayer2k

    on Nov 12, 2026

    More actions

    Same on Windows x64 in the Copilot desktop app 1.3.0, which still bundles CLI 1.0.106-8 (every runtime process on this machine is that version). App users don't have the 1.0.107 fix yet.

    Metadata only, for the WorkIQ plugin's client (ba081686-…): both entra-broker-cache\<id>.bin and entra-broker-accounts\<id>.bin are 0 bytes, so unlike the original report the account record wasn't written either.

    How it shows up in the app:

    • Since the plugin was installed three days ago, the logs show MCP OAuth authorization failed; reporting the server as needing auth with Browser-based OAuth required for https://workiq.svc.cloud.microsoft/mcp every day, and no successful connect.
    • The server's re-auth action in the app's MCP settings shows "Authorization update unavailable", so sign-in can't be completed from the app at all.

    Not verified yet: whether one sign-in from a 1.0.107+ terminal session carries over to the app's 1.0.106-8 engine.
11. bha7esh commented on Nov 13, 2026

    

    bha7esh

    on Nov 13, 2026

    Author

    More actions

    Confirmed on Windows x64 with Copilot CLI 1.0.111 and Agency 2026.11.12.6 (original reporter).

    • The EngHub HTTP MCP server (https://mcp.eng.ms) connected with no account picker. An EngHub search tool call succeeded in the same session.
    • Before this, a new process always showed the picker. This matches the fix reported for 1.0.107 in an earlier comment.
    • The cache file is still 0 bytes: entra-broker-cache\<id>.bin, last written 10/22. The accounts file is 1,974 bytes, last written 11/5. Metadata only, I did not read file contents.

    So the repeated prompt is fixed for me, but the cache file is still not written. The token seems to come from somewhere else.

    Not tested: a first sign-in on a clean profile, and a fresh process after a cold start. One headless -p run did not start EngHub at all, so I cannot say anything about headless mode.

    The desktop app problem in the latest comment (bundled CLI 1.0.106-8) is a separate case. I could not check it.
12. bha7esh

    closed this as completedon Nov 13, 2026