Update restart fires without user action, even with an update banner staged and unactioned

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 4 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
Frequency: at least four times in five days (2026-08-23 to 2026-08-27)

The defect

One profile had an update banner staged:

"updaterBannerStagedAt": { "version": "1.37937.1", "stagedAt": 1787712494076 }

That is 2026-08-25 21:48, matching [updater] Update downloaded and ready to install
{ releaseName: '1.37937.1' } the same second. The user did not act on it. The app restarted anyway
on 2026-08-26 at 20:04:14, to a later version, 1.37937.3.

The other two profiles have no updaterBannerStagedAt key at all.

A server-side flag is also raising the check rate fourfold:

[updater] Using GrowthBook check_interval_ticks=1 (default 4)

Version churn driving this

Five versions in four days, each a restart opportunity:

1.25927.0  ->  1.34493.1   (2026-08-23 / 08-24)
1.34493.1  ->  1.37937.0   (2026-08-25)
              1.37937.1    (downloaded 2026-08-25 21:48)
           ->  1.37937.3   (2026-08-26)

Expected behavior

Staging a banner and then restarting anyway makes the banner meaningless. If the app has decided the
user should be asked, it should wait for the answer.

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