disableAutoUpdates also hides Help > Check for Updates, removing the manual update path

Split out of anthropics/claude-code#90172, which reports eight interconnected defects arising from
one root cause: the desktop app restarts itself to apply an update and destroys the running Claude
Code sessions. That issue holds the shared context and the manual recovery addendum. This is
defect 7 of eight.

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

The defect

The app has a working manual update path at Help > Check for Updates. It is gated on the same flag
that controls automatic updates:

let t = GV() && W().autoUpdate.disabled !== !0;
switch (e.state) {
  case `idle`: case `error`:
    return [{ label: `Check for Updates…`, visible: t, click: () => Zfn(), id: n }, ...]
  case `ready`:
    return [{ label: `Restart to update to {updateVersion}`, visible: t, ... }]
}

visible: t is false whenever disableAutoUpdates is true. Setting the policy hides "Check for
Updates", "Downloading Update", and "Restart to update to X" alike. The entire update group vanishes
from the Help menu.

So the two available configurations are:

| Configuration | Unattended restarts | In-app update path |
|---|---|---|
| default | yes, kills running sessions | Help > Check for Updates |
| disableAutoUpdates=1 | none | none |

A user who wants to keep taking updates but choose when the restart happens has no configuration
that provides it. Turning off the unattended restart also removes the control they would use to
update deliberately. The remaining path is downloading the installer from
https://claude.com/download by hand.

Requested

Decouple these. Keep "Check for Updates" and "Restart to update to X" visible when
disableAutoUpdates is set, so the flag governs only whether the app acts on its own.

That single change would resolve the consent problem in this report without new UI.

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, this issue | 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.