[BUG] Cowork: MS365 MCP fully offline on Windows 11 — device code flow loops indefinitely, verify-login / list-accounts return network errors

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Custom MS365 MCP connector (@softeria/ms-365-mcp-server) is completely unreachable in Cowork on Windows 11 as of April 20, 2026. Every tool call to the MCP server returns network errors, and the device code authentication flow loops indefinitely — each login call issues a fresh code, browser sign-in completes successfully, but no token ever persists. This blocks ALL MS365-dependent skills.

Observed symptoms:

1. ms365:verify-login → "No valid token found" / network error
2. ms365:list-accounts → returns 0 accounts / network error
3. ms365:login --force → issues new device code; browser sign-in succeeds; retrying any MS365 tool call STILL returns "No valid token found"
4. Calling login again issues yet another fresh code (observed sequence: C6JWSMN3L → LN4XFPRVL → CR2JYSBKZ within minutes), each invalidating the prior — token is never persisted server-side
5. Reproducible across every new Cowork chat session today
6. Manual recovery (toggling connector OFF/ON in Cowork settings) does not restore service

What Should Happen?

After completing the device-code authentication in the browser, the MS365 MCP server should persist the obtained access token. Subsequent tool calls (verify-login, list-accounts, any Outlook/Calendar/OneDrive/Excel operation) should succeed without re-prompting for authentication. The token should survive across new Cowork chat sessions, not be re-requested on every fresh chat.

Error Messages/Logs

`ms365:verify-login` response: `"No valid token found"`
`ms365:list-accounts` response: 0 accounts returned
`ms365:login --force` response: device code issued (e.g., `C6JWSMN3L`), but no token persists after browser-side code entry succeeds

Sequence of fresh device codes issued within minutes in one session: `C6JWSMN3L` → `LN4XFPRVL` → `CR2JYSBKZ`. Each new `login` call invalidates the prior code, indicating the MCP server never stores the token returned by Microsoft's token endpoint.

Steps to Reproduce

1. Open Cowork on Windows 11 with the MS365 connector enabled in the chat's connector panel
2. Start a new chat session
3. Call any MS365 tool (e.g., ms365:verify-login)
4. Receive "No valid token found"
5. Call ms365:login --force
6. Receive a device code (e.g., C6JWSMN3L)
7. Open https://login.microsoft.com/device in browser, enter the code, complete sign-in successfully
8. Browser confirms sign-in success
9. Retry ms365:verify-login → still returns "No valid token found"
10. Retry ms365:login --force → issues a fresh device code (e.g., LN4XFPRVL), invalidating the prior
11. Loop never terminates; token is never persisted server-side

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — Cowork (Claude Desktop), latest as of April 20 2026 (exact build not captured)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

Impact

Total loss of MS365 functionality across all skills that use the MCP server: follow-ups, check-monday-tasks, check-hubspot-tasks, grace, manage-melissa, business-manager, proof-revision, every Outlook/Calendar/OneDrive/Excel-touching skill. Paid Max plan workspace running daily client-facing operations.

Possible relationship to known issues

This may be the same regression cluster reported in:

• "Cowork fails to start workspace on Windows 11 Pro — Request timed out: configure" (filed today, April 20)
• "SDK 2.1.111 regression: Failed to create bridge sockets — Claude Code process exits code 1 on every Cowork VM spawn (Windows 11, MSIX)" (April 17, multiple duplicates)
• "Cowork fails to install on Windows 11 Pro — HRESULT 0x80073CF6" (April 16)

If MCP connectors share the same bridge-socket transport that's failing in those reports, the auth loop here is a downstream symptom — token persistence isn't the root cause; the MCP server simply isn't reachable.

Triage history (please don't auto-close this one)

This is the third filing in this area:

• #34832 (filed March 16) — auto-closed by stale-bot at 03:40 UTC TODAY (April 20) as "not planned." Five comments, ZERO Anthropic dev engagement across 35 days.
• #45613 (filed April 8) — auto-closed April 12 as duplicate of #34832 (which has now also been closed).
• This issue (April 20) — filing per the stale-bot's own closing message: "Please open a new issue if this is still relevant."

The pattern of bot-driven closures without human triage is itself part of the problem this report documents.

Environment

• OS: Windows 11 Home (10.0.26200)
• Cowork (Claude Desktop): latest as of April 20, 2026 (exact build version not captured at filing time — happy to provide on request)
• MCP server: @softeria/ms-365-mcp-server v0.79.5
• Plan: Max (paid)
• Account: Streamline Branding workspace

Asks

1. Is this the same regression as the SDK 2.1.111 / bridge-socket cluster above, or a separate MCP auth path failure?
2. Can someone from the Cowork team acknowledge and assign this so it doesn't go stale a third time?
3. Is there a Cowork-side rollback or workaround for affected Windows 11 users while the underlying fix is built?

Happy to provide logs, repro recordings, or run any diagnostic the team wants.