[Bug] Staged desktop update is invisible: no update-ready indicator, silently deferred for days, then quits mid-session without warning

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

Summary

A staged desktop update is completely invisible to the user. There is no "update ready" indicator, no restart affordance, and no progress of any kind. The app silently defers its own auto-restart for days, then quits mid-session without warning.

On this machine, version 2.2553.1 finished downloading on 2026-09-18 18:32:51 and was applied on 2026-09-22 09:35. That is 3 days 15 hours during which the app knew it had an update ready and never said so. In between it logged Deferring auto-restart 100 times, silently, at 20-minute intervals.

This is a UX issue on its own, but it also makes #89912 much worse: when the relaunch then fails with 0x80070020, the user has no idea what just happened or that an update was even in flight.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| Package | Claude_2.110.0.0 → Claude_2.2553.1.0_x64__pzs8sxrjxfjjc |
| SignatureKind | Developer (sideloaded MSIX) |
| Claude Code | 2.1.220 |

What the log shows

Download completes, and then nothing is communicated:

2026-09-18 18:32:30  [updater] [evt:replacing-staged] Newer version 2.2553.1 available (staged: 2.2553.0)
2026-09-18 18:32:31  [updater] Found an update, downloading
2026-09-18 18:32:51  [updater] Update downloaded and ready to install { releaseName: 'Claude 2.2553.1' }

For the next three and a half days, every 20 minutes:

2026-09-14 07:47:05  [updater] Deferring auto-restart after 72 hours: Claude is working
     ... 100 occurrences, counter climbing 72h → 93h ...
2026-09-22 08:58:41  [updater] Deferring auto-restart after 93 hours: Claude is working

Then, with no warning and no user action, mid-session:

2026-09-22 09:34:39  [Stop hook] Query completed for session local_4feb9b45-...
2026-09-22 09:35:12  [popout-restore] Saving 1 session + 0 pane + 0 project popout(s) for next launch
2026-09-22 09:35:13  beforeQuitForUpdate handler fired, going down for update

Thirty seconds earlier the app was actively serving a session. The window simply disappears.

Note that this build takes the Deferring auto-restart path, not the idle path — stealth appears zero times in this machine's logs. The outcome is the same as #89912 (215/215/208 with 0x80070020, eleven consecutive failures, cleared only by reboot — details in #94432), but the trigger differs, so a fix aimed only at the idle path would miss this.

What the user sees

Nothing, at any stage:

• No indicator that an update has been downloaded and is waiting.
• No way to say "apply it now" at a moment of my choosing.
• No warning that the app is about to quit itself.
• When the relaunch then fails, only a Windows shell dialog naming a path under C:\Program Files\WindowsApps\ as "in use by another program". Nothing identifies it as Claude, as an update, or as recoverable by reboot.

If an update-ready affordance exists somewhere in the UI, it did not surface on this machine across seven staged updates since 2026-09-09.

Why the current design backfires

Deferring auto-restart ... Claude is working is clearly meant to be considerate. In practice it inverts:

• Because it waits for the app to be idle-ish, the restart lands at an arbitrary moment days later, which the user cannot anticipate.
• Because the deferral is invisible, the user has no way to say "now is actually fine" — e.g. before lunch, rather than 30 seconds into a long task.
• A 93-hour deferral means the user runs a stale build for days while a fixed one sits on disk.

Deferring is the right instinct; doing it silently and then deciding unilaterally is what hurts.

Suggested improvements

Roughly in order of value for effort:

1. Surface the staged update. Once Update downloaded and ready to install fires, show it — a badge, a menu item, something persistent. The app already has the exact state; it just never renders it.
2. Give the user the trigger. A "Restart to update" action they can press when convenient. This alone removes most of the pain, because the user picks a safe moment.
3. Warn before self-quitting. If auto-restart must happen unprompted, give a short dismissible countdown with a "not now" option, rather than vanishing mid-session.
4. Show progress during the relaunch. Currently the window disappears and nothing indicates work is in progress — indistinguishable from a crash.
5. Act on the stale marker. On the next successful start the app logs update_relaunch_marker: 'stale' — it already knows its own relaunch failed. Surface that as "the last update could not complete; a restart of Windows may be required" instead of leaving the user to find the Event Log.

Items 1–3 would also defuse #89912 for most users, since a user-initiated restart is the path that reliably works.