Desktop: after failed update + logout/login, all running local sessions show "Can't reach your computer" although their processes are alive on the same machine

Environment

• Windows 11 Pro (build 10.0.26200)
• Claude Code CLI 2.1.257
• Claude Desktop: 1.40609.1 (69aac0), built 2026-08-30T23:12:49Z (auto-updated 2026-09-01; the update initially failed to start)
• ~13 concurrent local Code-tab sessions across several projects (multi-session/worktree workflow)

What happened (timeline)

1. Claude Desktop auto-updated and then failed to start.
2. To recover, I logged out and logged back in to the desktop app.
3. The app now runs, but every local session that was running before the update shows "Can't reach your computer — It may be asleep or offline. This session will reconnect when it's back." The sessions display the local-session icon and their full transcript, and the machine they allegedly can't reach is the machine the app itself is running on.
4. Messages typed into such a session render in the transcript UI but are never delivered (details below). The card's promise ("will reconnect when it's back") never comes true, even hours later.
5. Sessions started after the login work normally. One pre-update session that happened to be actively running a task also recovered on its own.

Evidence gathered from a surviving session

A session that was active through the event could observe the machine state from the inside:

• All the "unreachable" sessions' claude.exe processes are still running. Task list shows ~13 of them, matching the pre-update session count. Nothing crashed; they are idle at their prompts.
• The surviving session's own cross-session identity changed mid-day — from <name>-b2 [a0ba50] to <name>-33 [704e4f] — without a restart. Its view of peer sessions collapsed from 13 entries to only sessions started after the login.
• Undelivered messages are UI-side only. I typed the same instruction three times into an unreachable session; the desktop UI shows all three bubbles, but the session's on-disk transcript (~/.claude/projects/<dir>/<session>.jsonl) does not contain them — they were queued somewhere upstream and never reached the local process.
• All affected sessions' transcripts share one final write timestamp (the moment of the event), across every project — consistent with a mass disconnect+flush rather than individual failures.

Interpretation (from the outside)

The logout/login appears to issue a new client/broker identity, while running local sessions remain registered under the old one. Re-registration seems to ride on session activity — the one active session transparently re-registered (its ref changed), while idle sessions never will, because they are blocked waiting for input that can no longer reach them. The result is a deadlock: the app can't deliver input to trigger the activity that would let the session re-register.

Impact

• Long-running working sessions (hours of context each) become unreachable while looking merely "asleep".
• The error text is misleading for this case: the "computer" is the local machine the app is running on.
• Typed messages appear accepted (rendered in the transcript) but are silently never delivered.

Workaround that works

Fully quit the desktop app, end the orphaned claude.exe processes (safe — idle, transcripts flushed), relaunch, and resume each session (reopen in the app, or claude --resume in the project directory). Context is preserved via the on-disk transcript; the undelivered messages must be re-typed.

Suggestions

• On logout/login (or broker identity change), actively re-adopt or terminate still-running local session processes instead of leaving them orphaned.
• If a local session's host process is alive but unregistered, offer an explicit "reconnect/resume" action rather than the passive "will reconnect when it's back".
• Distinguish "your computer is offline" from "the session process on this computer lost its registration" in the error card.
• Don't render undeliverable messages as if they were accepted — or deliver the queue on resume.