[BUG] Windows: desktop updater overrides its own "Claude is working" deferral and force-restarts mid-task, destroying a running unattended Claude Code job

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Related prior report: #92196 (macOS, closed as not planned by automation with "doesn't appear to be about Claude Code"). Filing this as a separate Windows report with log evidence that report did not have, rather than as a duplicate. I have also commented on #92196.

What happens

The desktop updater detects that a task is in progress, defers the restart because of it, logs that decision 42 times over 27 hours — and then restarts anyway at a fixed ceiling, killing the running work. No prompt, no warning, no setting to prevent it.

This is not "the update failed" (that is #53247 / #76357) and it is not a crash or a race. The app evaluates "is Claude working?", answers yes 42 times, and then overrides its own answer.

From %LOCALAPPDATA%\Claude\logs\main.log:

2026-09-15 01:32:33 [info] [updater] Deferring auto-restart after 74 hours: Claude is working
   ... 42 such lines over the following 27 hours ...
2026-09-16 03:22:50 [info] [updater] Deferring auto-restart after 100 hours: Claude is working
2026-09-16 03:32:50 [info] [updater] Staged version 2.110.0 is still current (latest: 2.110.0, lastTarget: 2.110.0)
2026-09-16 03:42:50 [info] [updater] Deferring auto-restart after 101 hours: Claude is working
2026-09-16 04:02:50 [info] [updater] Auto-restarting app after update pending for 101 hours

The final line fires while the same condition that produced the previous 42 deferrals is still true. There appears to be a hard ceiling around 101 hours at which the "Claude is working" guard stops being honoured.

Impact

The 04:02:50 restart terminated a live session running an unattended overnight maintenance job against a customer estate — antivirus agent replacement, ~10 machines per wave, 45–60 minutes per cycle.

Lost with the session:

• every background monitor tracking machines mid-cycle;
• a 15-minute watchdog whose only job is to detect a machine left without antivirus — the window between the old agent being removed and the replacement installing.

That watchdog was gone for four and a half hours while machines were in exactly that state. Nothing was surfaced anywhere; the operator found out the next morning.

The worker processes survived only because they had been launched detached. Everything tied to the session did not.

Why the current behaviour is wrong

1. The app knows it is interrupting. The condition is evaluated and logged 42 times. The information needed to avoid the harm is present and is deliberately overridden.
2. The user is never asked. No prompt, no notification, no restart-now/later choice.
3. The deadline is invisible. Nothing indicates an update will be forced in N hours, so there is no way to take the restart at a safe moment.
4. There is no opt-out. No key in any app config governs it. On this machine autoUpdates: false and DISABLE_AUTOUPDATER=1 are both set — they govern the CLI and have no effect on the desktop app's restart decision. That is a reasonable-expectation trap in its own right.
5. Unattended work is a supported use case and is precisely what the deferral logic exists to protect. It stops protecting it at the moment the pending update is oldest — i.e. it is weakest exactly when the user has been working longest.

What Should Happen?

In order of preference:

1. Never force a restart while a task is in progress. If the deferral condition holds, keep deferring. An out-of-date app is a far smaller harm than destroyed work.
2. Prompt before restarting — "an update is ready, restart now or in N hours?" — and honour the answer.
3. Expose a setting to disable or bound automatic restarts, documented alongside the CLI's autoUpdates.
4. Surface the pending deadline in the UI so the restart can be taken deliberately at a safe point.
5. At minimum, wait for genuine idle rather than firing on a timer regardless of state.

Also: either make the CLI's autoUpdates: false / DISABLE_AUTOUPDATER=1 govern the desktop app's restart behaviour, or document clearly that they do not and provide something that does.

Error Messages/Logs

`%LOCALAPPDATA%\Claude\logs\main.log` — the deferral loop and the override:


2026-09-15 01:32:33 [info] [updater] Deferring auto-restart after 74 hours: Claude is working
2026-09-16 03:42:50 [info] [updater] Deferring auto-restart after 101 hours: Claude is working
2026-09-16 04:02:50 [info] [updater] Auto-restarting app after update pending for 101 hours
2026-09-16 08:30:46 [info] [updater] Version changed since last launch: 1.52386.0 → 2.110.0
2026-09-16 08:30:46 [info] [CCD-autoupdate] Disabled: MSIX install
2026-09-16 08:30:47 [info] [updater] App is installed, enabling initial check and auto-updates
2026-09-16 08:30:47 [info] [updater] Update URL: https://api.anthropic.com
2026-09-16 08:30:47 [info] [updater] MSIX detected: windowsStore=true, appPathMatch=true, source=windowsStore
2026-09-16 08:30:47 [info] [event-loop-stall] update relaunch (stale marker) stands in for an unheard suspend


Package history, `C:\Program Files\WindowsApps` — note the ~2-day update cadence:


Claude_1.52386.3.0_x64__pzs8sxrjxfjjc   2026-09-12 00:02:16
Claude_1.52386.6.0_x64__pzs8sxrjxfjjc   2026-09-13 22:12:32
Claude_2.110.0.0_x64__pzs8sxrjxfjjc     2026-09-15 22:22:49   <- staged mid-session


**Minor, same log block:** `windowsStore=true` is wrong on this machine. `Get-AppxPackage` reports `SignatureKind: Developer` — a sideloaded MSIX installed from Anthropic's own download, not the Microsoft Store. The detection appears to infer "Store" from the `C:\Program Files\WindowsApps` path, which is also where sideloaded MSIX packages land. It actively misdirects diagnosis toward Microsoft Store update settings, which have no effect on this install. Happy to split this out if preferred.

Steps to Reproduce

1. On Windows, install Claude Desktop (MSIX, sideloaded from the Anthropic download — not the Store).
2. Start a long-running task in the desktop Code tab, ideally an unattended job with background monitors so the impact is visible.
3. Leave an app update pending and unapplied for several days while continuing to use the app, so the updater's pending-age counter accumulates. main.log will show [updater] Deferring auto-restart after N hours: Claude is working roughly every 20 minutes.
4. Keep a task running as N approaches ~101 hours.
5. Observe [updater] Auto-restarting app after update pending for N hours. The app restarts with the task still running, without prompting. The session and every background task attached to it are destroyed.

Note step 3 is not contrived — the app updates roughly every two days on this machine, so a pending update accumulating age while the machine is in daily use is the normal state.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.252 (Claude Code) — desktop app 2.110.0.0, updated from 1.52386.6.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Relationship to existing issues

• #92196 — same behaviour on macOS, filed 2026-09-04, closed as not planned by automation with "this doesn't appear to be about Claude Code". I believe that closure was mistaken: the thing destroyed is a Claude Code session and its background tasks, and the desktop app is the supported host for Claude Code on both platforms. I have added this Windows evidence as a comment there too.
• #53247 / #76357 — the aftermath of an update restart on Windows MSIX (EBUSY locks, CoworkVMService thrash, reboot required). Well documented already and not re-reported here.

Those two are distinct problems. #53247 is "the update breaks the app". This issue is "the app decided to restart into active work". Fixing the former would not fix this one — a clean, successful restart mid-job still destroys the job.

They do compound, though. On this machine the forced restart landed in the #53247 state as well: the operator had to reboot the whole machine and close unrelated applications to get Claude working again. So a single unrequested update cost the overnight job and a machine reboot.

Environment detail

Get-AppxPackage -Name *Claude*
  PackageFullName  : Claude_2.110.0.0_x64__pzs8sxrjxfjjc
  Version          : 2.110.0.0
  SignatureKind    : Developer          <- sideloaded, not Store
  Publisher        : CN="Anthropic, PBC"
OS: Windows 11 Enterprise, build 26200

Full main.log extract and AppX package history available on request.