Update restart fires long before the autoUpdaterEnforcementHours deadline
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 6 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
autoUpdaterEnforcementHours defaults to 72 and was never configured on this machine, so the
documented force-install deadline was 72 hours. Both observed restarts fired far sooner:
| Profile | Update downloaded | Restarted | Elapsed |
|---|---|---|---|
| desktop-1 | 2026-08-26 19:07:50 | 2026-08-26 20:04:36 | 57 minutes |
| desktop-4 | 2026-08-25 21:48:14 | 2026-08-26 20:04:14 | 22 hours |
Neither is close to 72 hours. Something other than the enforcement window is triggering the restart.
The stealth-relaunch code captures window visibility and minimized state before quitting, which
suggests an idle or hidden-window heuristic.
If that is the trigger, it is misreading the state. The desktop-1 restart happened 12 seconds after
a session finished a turn, with nine sessions live.
Expected behavior
Either honour autoUpdaterEnforcementHours as the documented deadline, or document what else can
trigger a restart before it. As it stands the setting does not describe the behavior.
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, this issue | 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.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Still open. Defect 6 of the eight split out of #90172.
autoUpdaterEnforcementHoursdefaults to 72 and was never configured on this machine, so the documented force-install deadline was 72 hours. Both observed restarts fired far sooner: 57 minutes on one profile and 22 hours on another.So something other than the enforcement window is triggering the restart. The stealth-relaunch code captures window visibility and minimized state before quitting, which points at an idle or hidden-window heuristic. If that is the trigger it is misreading the state, because one of those restarts happened 12 seconds after a session finished a turn, with nine sessions live.
Either behaviour would be defensible on its own. What is not is a documented setting describing a deadline that does not govern. Honour
autoUpdaterEnforcementHours, or document what else can fire a restart before it, so an operator can reason about the window they actually have.Still open. On #90870, another user added a third interval: 16 minutes from staging to forced shutdown, on a machine where
autoUpdaterEnforcementHourswas never set, so the 72-hour default applied.They also report the app was in active use at that moment, with the window focused. That argues against an idle or hidden-window trigger misreading the state, or at least shows the trigger fires in active use. Either way, the documented 72-hour window is not what decides when the restart happens.
This is very disruptive indeed,. claude just restarts itself (again), and something is locking a file which prevents the updater from running.
Forcing you to go into zombie thread hunting mode, or just rebooting the PC.