No update policy that downloads an update and waits for the user to install it
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 5 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 gap
The app exposes exactly two update policy keys, both under the managed tier
(HKLM\SOFTWARE\Policies\Claude on Windows):
| Key | Type | Meaning |
|---|---|---|
| disableAutoUpdates | boolean, default false | "Stop Cowork from fetching updates entirely (no time limit). You'll need to push new versions yourself." |
| autoUpdaterEnforcementHours | integer, 1 to 72, default 72 | "Hours before a downloaded update force-installs. Only applies when auto-updates are enabled." |
Neither offers consent. The choice is all updates and unattended restarts, or no updates at all and
a manual distribution path. A user who wants updates but wants to choose when the restart happens
has no supported setting.
The app already has a manual install path. Its telemetry event is desktop_update_manual_install,
carrying update_version, pending_hours and source. So the machinery to let a user trigger the
install exists. It is just not possible to make it the only path.
Requested
A third option that downloads the update and waits for the user to install it, with no forced
restart.
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, this issue | 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.
3 Comments
Still open. Defect 5 of the eight split out of #90172, and the only one in the set that is a feature request rather than a bug.
The gap is that the app exposes two update policy keys and neither offers consent.
disableAutoUpdatesstops fetching updates entirely, andautoUpdaterEnforcementHoursonly sets how long before a downloaded update force-installs. So the choice is all updates with unattended restarts, or no updates and a manual distribution path. A user who wants to keep taking updates but choose when the restart happens has no supported setting.The machinery for the missing policy already exists. There is a manual install path, and its telemetry event
desktop_update_manual_installcarriesupdate_version,pending_hoursandsource. What is missing is the ability to make that path the only one. #90873 is why the workaround does not help either: settingdisableAutoUpdatesalso hides Help > Check for Updates, so it removes the manual path at the same time.Still open. On #90870, another user measured 16 minutes between an update being staged and the app being force-closed. In that case no update banner was ever shown. So the one consent point that exists in the UI today does not reliably appear.
A policy that downloads the update and then waits for the user to install it would not depend on a banner at all. That is the gap this issue asks to close: keep receiving updates, and choose when the restart happens.
Still open. #98429, from another user, asks for much the same control from a different use case: an update window, or deferring the restart while Remote Control is connected. Their machine is a Remote Control host, and an update restart during the day ends remote access until they are physically back at it.
That is a second, independent request for choosing when the restart happens. The policy asked for here would cover it: download the update, then wait for the user to install it. An update window would be a reasonable alternative shape for the same control.