Desktop update restart kills running Claude Code sessions: the stealth relaunch restores the window but not the sessions
Split out of anthropics/claude-code#90172, which reports eight interconnected defects arising from
one root cause. That issue holds the shared context and the manual recovery addendum. This is
defect 1 of eight, and it is the core defect: everything else in that report is secondary to it.
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-27
Frequency: at least four times in five days (2026-08-23 to 2026-08-27), and again on 2026-08-29
Summary
The desktop app restarts itself to apply an update. Its "stealth relaunch" restores the window and
navigation history, but it does not restart the Claude Code CLI child processes that the quit
killed.
The sidebar session cards survive, because those records live on the server. So the sessions look
present and healthy after the restart. Opening one and sending a message fails withRemote Control host unreachable (computer_unreachable).
The restart is designed to be invisible. That is what makes it harmful: the user has no signal that
the processes behind their sessions are gone.
One such restart killed nine running sessions.
An unattended restart destroys in-flight work with no warning, no consent, and no way to resume from
inside the app. The cost is real: lost session context, hours of re-establishing state, and the paid
tokens spent rebuilding what the restart threw away.
Evidence
Log from a single restart, one profile:
2026-08-26 20:03:53 [info] [popout-restore] Saving 0 session popout(s) for next launch
2026-08-26 20:03:54 [info] beforeQuit: handler fired, going down
2026-08-26 20:03:54 [info] Running onQuitCleanup: local-session-stop-all
2026-08-26 20:03:55 [warn] [pty-host] worker exited (0) with 9 live PTY(s); refork on demand
2026-08-26 20:03:55 [info] Shell PTY for session local_<id>-... exited with code 1
... eight more sessions, same second ...
2026-08-26 20:03:55 [info] willQuit: handler is ready for quit, so quitting
2026-08-26 20:04:36 [info] Starting app { appVersion: '1.37937.3' }
2026-08-26 20:04:36 [info] [updater] Version changed since last launch: 1.34493.1 -> 1.37937.3
2026-08-26 20:04:36 [info] [update-restart] Detected nav-restore marker, launching normally
2026-08-26 20:04:36 [info] [stealth-relaunch] Loaded navigation history (50 entries, active=49)
2026-08-26 20:04:36 [info] [stealth-relaunch] Restoring navigation (50 entries, active=49, dropped=0)Nine sessions were killed at 20:03:55. The relaunch 41 seconds later restored 50 navigation entries
and zero sessions. Nothing in the log restarts them.
The [update-restart] Detected nav-restore marker line proves this was app-initiated. The marker is
written by the app before it quits. A user-initiated launch does not produce it.
The quit itself logs no reason. It fires 12 seconds after a session finished a turn.
Recurrence on 2026-08-29, and a case with nothing left to recover
Same machine, two days after the first report. Nine sessions lost their host process in a single
instant again. The app version did not change across it, at 1.37937.3, so app-version churn is not a
necessary condition.
Other live sessions on the box call ListAgents routinely, which enumerates every session the Remote
Control bridge knows about, with status. Those tool results are timestamped inside the CLI
transcripts, so the timeline is measured with no new instrumentation:
| Time (UTC) | Remote Control rows, every one reading offline |
|---|---|
| 03:05:32 | none |
| 11:11:04 | 1 |
| 11:18:58 | none |
| 16:02:41 | 9 |
| 16:04:46 | 3 |
| 16:06:27 | 1 |
| 17:43:30 | none, they aged out of the roster |
Six of the nine came back, because something respawned them locally: ten new claude processes
carry start times between 16:01:55Z and 16:05:04Z. Three auto-named ones never got a replacement and
stayed dead.
Those three are unrecoverable by any route in the umbrella report. When the kill lands before a
session's first turn, no transcript is ever written, so the reconstruction method in the addendum
has nothing to work from:
| 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 |
Impact
- Nine running sessions destroyed in a single restart, with no warning and no recovery path inside
the app. Twice, five days apart.
- Session cards remain in the sidebar and appear healthy. Clicking one and sending a message returns
computer_unreachable. There is no indication the process is gone.
- Real cost to the user: destroyed work, hours spent diagnosing why sessions were unreachable, and
paid tokens consumed rebuilding context that the restart discarded. None of it was recoverable
through the app.
Expected behavior
- Do not restart for an update while sessions are running, or restore them afterwards.
- If a restart must happen, tell the user first, and say what will be closed.
How to reproduce
- Run the desktop app with one or more Claude Code sessions running.
- Leave them running while an update lands.
- After the restart, note that the window looks unchanged and the session cards are still listed.
Open one and send a message.
Observed: Remote Control host unreachable (computer_unreachable).
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, this issue | 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 | 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.