Every installed desktop profile restarts at once, because their update timers stay in lockstep

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 3 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

Three profiles restarted within 23 seconds of each other:

| Profile | Restarted | Version jump |
|---|---|---|
| desktop-4 | 2026-08-26 20:04:13 | 1.37937.0 -> 1.37937.3 |
| desktop-5 | 2026-08-26 20:04:26 | 1.37937.0 -> 1.37937.3 |
| desktop-1 | 2026-08-26 20:04:36 | 1.34493.1 -> 1.37937.3 |

Each profile runs its own update check on a fixed hourly offset, and those offsets match the
restart times exactly:

2026-08-27 04:04:15 [info] [updater] Checking for updates     <- desktop-4
2026-08-27 04:04:27 [info] [updater] Checking for updates     <- desktop-5
2026-08-27 04:04:37 [info] [updater] Checking for updates     <- desktop-1

Because the profiles were themselves launched seconds apart, their timers stay in lockstep and
they all restart together. The user is left with several app instances they did not start, which
is how this was first noticed.

Impact

Multiple unrequested app instances accumulate. Together with defect 1, one update event takes out
every running session on the machine at once, rather than one profile's worth.

Expected behavior

Stagger or coordinate restarts across profiles instead of restarting all of them.

How to reproduce

1. Install two or more desktop profiles, each with its own --user-data-dir, and launch them

within a few seconds of each other.

1. Leave them running until an update lands.

Observed: all of them restart within seconds of each other, on the same offsets their update checks
fire on.

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