Windows: all desktop sessions unreachable when a shared Remote Control host dies; false "Claude.ai login expired" while credentials are valid

[GENERIC-MODE]

Title

Windows: all desktop-app sessions become permanently unreachable (computer_unreachable) when a shared Remote Control host dies; no in-app recovery

Environment

• OS: Windows 11 Pro 10.0.26200
• Claude Desktop: 1.34493.1.0 (MSIX / WindowsApps install)
• App-managed claude-code runtime: 2.1.237
• npm-global claude-code CLI: 2.1.240 (separate install, on PATH)
• Surface: Claude Code desktop app on the same machine (not browser, not phone)

Symptom

Every session card in the desktop app shows:

Can't reach your computer
It may be asleep or offline. This session will reconnect when it's back.
Remote Control host unreachable (computer_unreachable)

This affects all sessions simultaneously, not a subset. Messages typed into any
card sit at "Sending..." indefinitely. The state does not clear on its own.

Why this is a bug, not expected behavior

1. The sessions are local. They live on this machine. The desktop app is running

on that same machine. It should not require a cloud round-trip through Remote
Control to reach a session whose transcript is on local disk.

1. Remote Control was never enabled, and there is no opt-in signal anywhere. The

CLI exposes it as an opt-in flag (--remote-control [name]); it was never passed.
The affected sessions were created in the desktop app and titled by hand by the
user. Nothing about them was auto-generated. How they came to be bound to a
Remote Control host is unexplained, and identifying where that binding
originates is the core of this report — from the user's side it appears to have
happened with no action on their part and no indication it had happened, until
every session failed at once.

1. A full reboot does not recover it. Machine restarted, app fully quit and

relaunched. Every card still reports computer_unreachable.

1. There is no in-app recovery path. The only way back into any session is

claude --resume from a terminal. Nothing in the UI offers to re-attach a
stranded session or fall back to the local transcript, and the cards do not
self-clean. Appears related to the known stranded-dead-card behavior in
anthropics/claude-code#69602.

Evidence collected locally

All of the following were verified on the affected machine:

• Data is intact. 1,402 .jsonl transcripts, 1.3 GB, under the local projects

directory. The 12 most recently written all parse as valid JSONL through the final
line. Nothing was lost or truncated.

• Nothing crashed. The app's Crashpad reports/ directory is empty. Zero dumps.
• Nothing is orphaned. All 18 live claude.exe / node.exe processes trace back

to the Electron main process. Orphan count: 0.

• Exactly one live agent process existed at diagnosis time, corresponding to the

one session that was reachable.

• The host is not registered. An in-session agent listing reports no reachable

agents, consistent with no Remote Control host bound to this machine.

• The Remote Control binding leaves no trace on disk. A case-insensitive search

across all 1,402 transcripts for remoteControl, remote_control,
remote-control, teleport, computer_unreachable, and computerId returns
zero matches in zero files. The sessions themselves carry no Remote Control
state whatsoever. The binding — and therefore the failure — exists only in
cloud/app-side session state, never in the user's data.

• Two claude-code installs are present at different versions (app-managed 2.1.237 vs

npm-global 2.1.240). Noted for completeness; not believed causal.

The error message is factually wrong, and this is the costliest part

On resuming an affected session locally, the client reports:

Remote Control disconnected - Claude.ai login expired - run /login, then /remote-control

The login was not expired. Inspected on disk at the moment the message was shown
(field names only, no secret values read):

claudeAiOauth.expiresAt              valid, ~7.1 hours remaining
claudeAiOauth.refreshTokenExpiresAt  valid, ~27 days remaining

The credentials file had been rewritten earlier the same day, i.e. the token had
refreshed successfully. Both tokens were valid when the client claimed the login had
expired.

This appears to be a generic Remote Control handshake failure being surfaced as a
specific and incorrect auth diagnosis. The cost is not cosmetic: it sends the user to
/login, then to reinstalling, rebooting, and quitting - none of which can affect a
server-side condition - while the true state (transcripts intact, sessions resumable)
is never surfaced. A generic "Remote Control unavailable" with a local-resume hint
would be strictly more accurate and far less destructive of the user's time.

Why the on-disk result matters

The local transcripts are entirely clean of Remote Control state. Three consequences:

1. claude --resume works flawlessly on every affected session, because there is no

RC entanglement in the data to fail on.

1. The "deadness" is purely a cloud-side record. No local repair is possible, and no

amount of restarting, relaunching, or reinstalling on the user's machine can
affect it.

1. The user had no way to know their sessions were RC-bound. Nothing on their

machine recorded it. The first indication was every session failing at once.

Impact

A single shared Remote Control host can back many concurrent sessions. When that host
dies, every session it carried strands at once and stays stranded. For a user with
a large session history this presents as total, permanent loss of access to all work,
with no indication in the UI that the underlying transcripts are fine and locally
readable. The actual data loss is zero; the perceived data loss is complete.

Expected behavior

Any one of these would resolve it:

1. The desktop app reaches local sessions locally, without a Remote Control round-trip.
2. A stranded card offers "reconnect" / "resume locally" in the UI rather than a dead

banner.

1. The banner states that the transcript is safe on disk and names the local recovery

command, instead of only "will reconnect when it's back" — which is not true when
the host is gone for good.

Likely root cause of the silent binding

Every local session record carries:

"remoteControlAutoEligible": true

The user never passed --remote-control and never enabled it in the UI. If this flag
is what opts a session into Remote Control hosting, then sessions are being bound
automatically, and the user is given no signal that it happened until the host dies
and every session fails at once. That would explain both "I never turned it on" and
"all of them died together."

Workarounds, both confirmed working

1. Terminal resume. claude --resume lists local transcripts and reattaches with
full history. Unblocks the work, but is useless to a user who works in the desktop app.

2. Re-register the transcript as a LOCAL session (desktop app). The desktop app's
local session records live in:

%APPDATA%\Claude\claude-code-sessions\<uuid>\<uuid>\local_<uuid>.json

Each is pure metadata - a pointer, not a copy. The conversation is loaded from the
.jsonl named by cliSessionId, found under the transcript directory derived from
cwd. Writing one new record per orphaned transcript, with:

sessionId                   local_<fresh uuid>
cliSessionId                <existing transcript uuid>
cwd / originCwd             <the project directory>
title                       <any title>
remoteControlAutoEligible   false

makes the session appear in the desktop app as a normal local session, with full
history and no Remote Control in the path. Verified on 8 sessions ranging from 0.2 MB
to 46 MB; all opened correctly.

Notably, the app validates and normalizes these records - it rewrote a supplied
lastActivityAt with the true last-event timestamp read from the transcript. So the
data needed to present these sessions locally is fully available to the app already.
It simply is not offered as a recovery path when Remote Control is down.

Caveat observed: after re-registration, the stranded Remote Control card and the
working local session coexist in the list with identical titles and no visual
distinction. Users will click the dead one.

Suggested minimum fix

When a Remote Control host is unreachable, the app already has everything needed to
open the session locally. Offer that instead of a dead card - or at minimum, stop
reporting "Claude.ai login expired" when the credential is valid.