A session card renders as live when no process backs it, and the failure is reported as computer_unreachable

Split out of anthropics/claude-code#90172. That report covered eight defects arising from one root
cause, the desktop app's unattended update restart. This is a ninth, carved out of defect 8
(#90874) because the evidence shows it is not downstream of the restart, or of anything else in
that report.

Product: Claude Desktop (Claude Code desktop app)
App version: 1.37937.3 (bundled CLI 2.1.246)
Platform: Windows 11 Pro 10.0.26200, x64
Reported: 2026-08-31

The defect

A sidebar session card renders as live when no process backs it. Sending a message into it fails
with a message describing a fault that is not happening:

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)

The card is server-side, so it survives whatever happened to the local process. Nothing in the UI
distinguishes a card with a running host from a card with none until the user sends into it and the
send fails.

The message is false

Measured on the machine at the moment the banner was rendering, by a second session, then
reproduced independently:

| Check | Result |
|---|---|
| Uptime | 4d 03h, no reboot |
| Kernel-Power 41/42/107/1 in preceding 12h | 0 events |
| TCP 443 to claude.ai | succeeded |
| TCP 443 to api.anthropic.com | succeeded |

The machine was awake, online, and running the very app displaying the message.

The failure taxonomy appears to have no category for "the local process backing this session is
gone," so it borrows the remote one. The result sends users to diagnose sleep settings, network
adapters and firewalls for a fault that is a dead child process on the same machine.

Three ways to reach the same card, only one of which involves a restart

This is why the defect is filed on its own. The banner is the generic rendering for "there is no
host process", and a normally-exited session produces it as reliably as a destroyed one.

| Case | Restart involved | CLI transcript | In the agent registry | Card |
|---|---|---|---|---|
| A. Killed by the update restart | yes | survives, in the pre-restart config dir | no | live-looking, sends fail |
| B. Killed before its first turn | yes | never written | no | live-looking, sends fail |
| C. Short-lived --bg session that exited normally | no | exists, in the correct per-account root | never entered | live-looking, sends fail |

Case A is #90867. Cases B and C are the reason this is not a restart defect.

Case C, measured

A claude --bg session was started from a Bash tool call inside a running desktop session. It was
given a prompt, answered it, and exited. That is the documented behaviour of --bg with a prompt.
Its card stayed in the sidebar showing the banner, and it survived stopping four sibling sessions.

| Fact | Value |
|---|---|
| Session name | skeptic-life-a |
| Session id | c25ed2ba-1900-46bc-aa2c-27ef1c2ed7de |
| First record | 2026-08-31T01:15:04.948Z |
| Last record | 2026-08-31T01:15:12.349Z |
| Total lifetime | 7.4 seconds |
| App version | 1.37937.3 |
| CLI that ran it | 2.1.251 (the one on PATH) |
| CLI bundled in the app | 2.1.246 |
| Last app quit before it | 2026-08-30 18:24:58 |
| Last app start before it | 2026-08-30 18:51:11 |
| App quits or restarts after it | none |

main.log for this profile carries no beforeQuit, no local-session-stop-all, no
[stealth-relaunch] and no [update-restart] marker after 18:51:11. The session was created and
died more than two hours later, entirely inside one app lifetime.

It was never in the local agent registry. claude agents --json does not list it under any of
the six config roots on this machine:

.claude             skeptic-life-a=0   named sessions listed=0
.claude-account-1   skeptic-life-a=0   named sessions listed=0
.claude-account-2   skeptic-life-a=0   named sessions listed=1
.claude-account-3   skeptic-life-a=0   named sessions listed=0
.claude-account-4   skeptic-life-a=0   named sessions listed=0
.claude-account-5   skeptic-life-a=0   named sessions listed=0

The named sessions listed=1 on .claude-account-2 is the positive control: that root does list a
session, so the query works and the zeroes are a real absence rather than a broken command.

The registry is not simply dropping exited sessions either. Four sibling --bg sessions spawned
minutes earlier were listed the whole time, including after they finished, with state=done and
state=blocked. Those four had ids, and claude stop <id> cleared them cleanly. This one never
appeared, so there is no id to pass to claude stop or claude rm.

A card with no registry entry cannot be addressed by any CLI verb.

Its transcript does exist, in the correct per-account root:

.claude-account-2\projects\<encoded-cwd>\c25ed2ba-1900-46bc-aa2c-27ef1c2ed7de.jsonl    29 lines

The file's own records carry sessionId equal to its filename, so it is that session's own
transcript rather than a mention of it elsewhere. It holds the full exchange the card displays.

Case B, measured

From the 2026-08-29 recurrence reported on #90867: three sessions were killed before their first
turn. They left a sidebar card and nothing else.

| Check | Result |
|---|---|
| CLI transcript for any of the three | none exists |
| Every .jsonl under ~/.claude*/projects modified that day | 16 files, each mapping to a different live local session |
| Any .jsonl written under the user profile in the six hours before the kill | none belonging to a session |
| Desktop app session store, include_archived: true | 35 sessions, none of the three |
| Every roster sighting of the three, first to last | offline, without exception, never once seen online |

A card with no local record and no transcript is not a session in a bad state. It is not a session
at all, and it should not render as one.

Why this is worth separating from the restart

1. The error text is wrong for cases B and C and misleads. Nothing is asleep, nothing is

offline, and it will never reconnect. A session that ran for 7.4 seconds and exited successfully
is reported in the language of an unreachable machine.

1. It weakens the restart signal. Anyone spawning background sessions accumulates these cards

during normal operation. Once Can't reach your computer is a routine sight, it stops
functioning as evidence that a restart destroyed something.

1. Case C is a reliable reproduction that needs no update, no restart and no waiting. If it

holds on other machines it makes the card lifecycle testable directly, without having to catch a
stealth relaunch in the act.

How to reproduce

1. From inside a running desktop session, start a short claude --bg session with a prompt it can

answer in one turn.

1. Let it answer and exit. Do not restart or quit the app.
2. Look at its card in the sidebar.

Observed: the card renders as a live session and shows Can't reach your computer / It may be
asleep or offline. This session will reconnect when it's back. It cannot be cleared with
claude stop or claude rm, because it never entered the agent registry.

Requested

1. Distinguish "local session process is gone" from "remote host unreachable" and give the

first its own message. It is not a connectivity problem and should not be described as one.

1. Do not present a session card as live when no process backs it. Mark it dead on load, rather

than failing when the user sends a message into it.

1. Do not render a card at all when there is no local record and no transcript. That is case B,

and it is not a session.

1. Give the user a way to dismiss a card whose session is unreachable by any CLI verb. Case C

has no id to pass to claude stop, so today the card cannot be removed.

The nine defects

Eight were reported together in #90172, because they come from one root cause. The
ninth was carved out of defect 8 once the evidence showed it is reachable with no
restart involved. Each is filed separately so it can be triaged and closed on its own.

| Defect | Issue | What it is |
|---|---|---|
| 1 | #90867 | The update restart kills running sessions. The relaunch restores the window, not the sessions. Core defect. |
| 2 | #90868 | The relaunch does not preserve CLAUDE_CONFIG_DIR, so sessions register into the default config directory. |
| 3 | #90869 | Every installed profile restarts at once, because their update timers stay in lockstep. |
| 4 | #90870 | The restart fires without user action, even with an update banner staged and unactioned. |
| 5 | #90871 | No update policy downloads an update and waits for the user to install it. |
| 6 | #90872 | The restart fires long before the autoUpdaterEnforcementHours deadline. |
| 7 | #90873 | disableAutoUpdates also hides Help > Check for Updates, removing the manual update path. |
| 8 | #90874 | Local sessions are auto-registered with the cloud Remote Control bridge, with no opt-in step. |
| 9 | #90877, this issue | A session card renders as live when no process backs it, and the failure is reported as computer_unreachable. Carved out of defect 8; reachable with no restart involved. |

Shared context, impact, and the manual session-recovery addendum stay on the umbrella
issue #90172. The updater mechanism underneath defects 1 to 7 is filed separately as
#86556: a staged Squirrel build is applied on any relaunch, not only on the
"Relaunch to update" consent gate.