[BUG] Desktop (Windows): a forced re-authentication mid-session silently drops the prompt just submitted in another session

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?

Summary
The Claude Desktop app forced a sign-out and re-authentication while several Code-tab sessions were open. The app processes were never killed, and after re-auth everything looked normal, but a prompt submitted about 25 seconds before the re-auth was never processed. The text reached the session transcript on disk and then simply received no response. Nothing in the UI indicated that a submitted prompt had been abandoned.

The prompt is the last user entry in that session's transcript and is followed only by attachment and metadata records, with no assistant turn. The only reason the text was recoverable at all is that transcripts are written to disk.

---

Environment
Windows 11 Pro 25H2 (build 26200.9445); Claude Desktop MSIX 2.110.0.0; bundled Claude Code CLI 2.1.271; several Code-tab sessions open; connectors configured as local user-scope MCP servers.

What Should Happen?

Expected
Either the prompt is re-submitted automatically once authentication succeeds, or the session surfaces it as unsent with a retry affordance. A submitted prompt should never be discarded without any indication to the user.

Error Messages/Logs

19:07:47  prompt submitted in Code-tab session A; written to that session's transcript (2,479-character user entry)
19:08:11  [oauth] clearing latched session_stale_relogin failures
19:08:11  [growthbook] refreshing for account change
19:08:31  [oauth-v2] performing fresh /authorize for orgId=<redacted>
19:08:32  [oauth-v2] credential widened to user:plugins
19:09:04  [oauth-v2] using cached token
19:10:34  [remote-tools-device] authenticated

Throughout: 34 claude.exe processes remained alive; no crash events in the Windows Application log.
Result: the 19:07:47 prompt is the last user entry in the transcript, followed only by attachment/metadata records. No assistant turn was ever produced for it.

Steps to Reproduce

Steps to reproduce

1. Open several Code-tab sessions in the Claude Desktop app on Windows and leave them running.
2. Submit a prompt in one session.
3. Within roughly 30 seconds, the app forces a sign-out and re-authentication on its own. In the log this appears as [oauth] clearing latched session_stale_relogin failures, then [growthbook] refreshing for account change, then [oauth-v2] performing fresh /authorize.
4. Complete the sign-in when prompted.
5. Return to the session from step 2 and observe that the prompt is present in the conversation but never received a response, with no error, warning or retry control shown.

Note on reproducibility: the trigger is app-initiated, not user-initiated, so this cannot be forced on demand. It is detectable after the fact by comparing the session transcript on disk against the app log timestamps, which is how it was identified here.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.271

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Why this matters
The re-authentication is not user-initiated and gives no warning, so there is no opportunity to protect work in flight. In a multi-session workflow the loss is easy to miss: the session still looks healthy afterwards, and the missing response is easily mistaken for the model simply not having replied yet. The prompt in this case was a long, carefully composed instruction block, and it was recovered only by reading the session transcript from disk.

---

Requests

1. Queue and re-submit, or explicitly surface as unsent, any prompt that was in flight when a forced re-auth occurs.
2. Warn before forcing re-authentication while sessions are active, and let the user finish or cancel.
3. Log the discard explicitly so it is diagnosable rather than silent.

---

Related
#92246 covers the app's silent auto-update relaunches on Windows, the same class of unrequested interruption; I commented there with logs. #91589 covers connector schemas being stripped when the app respawns Code sessions with --resume after such a restart. This issue is specifically about the authentication path discarding a submitted prompt.