Windows desktop app self-updates and restarts over a running session — nine forced restarts in nine days, no opt-out

## Summary

The Claude desktop app on Windows updates itself by stopping its own service, swapping its MSIX package, and restarting. Any work running in the app at that moment ends. There is no prompt, no deferral, and no setting to postpone it.

It has happened **nine times in nine days** on one machine, including three times during working hours and once at 03:17 local, which ended roughly **seven hours of unattended overnight work**.

## Impact

- **2026-09-05, 03:17 local.** A long-running unattended session was in progress. The app updated itself and restarted. Seven hours of work that would have run overnight did not happen. Nothing was recoverable, because the loss was elapsed time rather than saved state.
- **Three of the nine updates landed mid-day** — 2026-09-03 08:34, 2026-09-03 12:41, 2026-09-04 11:55 — so this is not confined to idle hours.

## Environment

| | |
|---|---|
| OS | Windows 11 Home, 10.0.26200 |
| App | Claude 1.46388.3.0, x64 |
| Package family | `Claude_pzs8sxrjxfjjc` |
| Install location | `C:\Program Files\WindowsApps\Claude__x64__pzs8sxrjxfjjc` |
| SignatureKind | **Developer** — sideloaded MSIX from anthropic.com, **not** a Microsoft Store install |
| Locale | UTC+09:30; all timestamps below are local |

## Every version registered on this machine

From `Microsoft-Windows-AppXDeploymentServer/Operational`, event ID 400 ("Deployment Register operation … finished successfully"), earliest registration per version. The log's own retention starts 2026-08-27, so this is a floor, not a total.

| Version | First registered (local) |
|---|---|
| 1.37937.3.0 | 2026-08-27 11:36:10 |
| 1.40609.0.0 | 2026-08-29 03:25:57 |
| 1.40609.1.0 | 2026-09-02 04:42:03 |
| 1.44121.1.0 | 2026-09-02 23:43:22 |
| 1.44121.2.0 | 2026-09-03 08:34:03 |
| 1.44121.4.0 | 2026-09-03 12:41:27 |
| 1.46388.1.0 | 2026-09-04 11:55:50 |
| 1.46388.2.0 | 2026-09-04 17:26:13 |
| 1.46388.3.0 | 2026-09-05 03:07:22 |

Nine versions across nine days. Two on 2026-09-03 and two on 2026-09-04.

## The exact sequence, 2026-09-05

From the Windows **Application** log and **AppXDeploymentServer/Operational**, same machine, same minute:

```
03:07:22 AppX Claude_1.46388.3.0 registered
03:17:53 App log CoworkVMService: "Claude VM Service stopped."
03:17:53 App log CoworkVMService: warning, failed to disarm SCM recovery actions for this stop
03:17:54 AppX event 2562
03:17:54 AppX event 472 — moving package folder Claude_1.46388.2.0_x64__... to WindowsApps\Deleted\...
03:17:54 AppX event 400 — Deployment Register on Claude_1.46388.3.0 finished successfully
03:17:54 AppX event 613 — overall time 1109 ms (active 1109 ms)
03:17:54 AppX event 617 — status updated for the package
03:17:54 App log CoworkVMService: "Claude VM Service starting."
03:17:54 App log CoworkVMService: warning, failed to configure SCM recovery actions
```

**There is no crash.** `%APPDATA%\Claude\Crashpad\reports` holds no report for this time and the Application log carries no fault entry. The app stopped its own service, replaced its own package, and started again — an orchestrated self-update, not a failure.

The visible symptom is a dialog reading:

> `C:\Program Files\WindowsApps\Claude_1.46388.3.0_...`
> **Another program is currently using this file.**

The "another program" is Claude itself, holding files from the version being replaced. The message misattributes the cause and gives the user nothing to act on. It has appeared at least twice, including once **without** a restart, so the condition can also be hit and survived.

## What was ruled out

- **Not the Microsoft Store.** `SignatureKind` is `Developer`, so the package was sideloaded from anthropic.com. Store update settings do not apply and turning them off changes nothing.
- **Not Windows AppInstaller polling.** `Get-ScheduledTask` finds no task matching `*AppInstaller*` or `*Claude*`. Nothing on the OS side is scheduled to check.
- **Not another application.** At the time of the 03:17 restart the machine was running only a browser and Claude.
- **Not a user-side setting.** `%APPDATA%\Claude\config.json` contains updater *state* — `updaterLastSeenVersion`, `updaterBannerStagedAt`, `version_first_launch` — but no updater *setting*. There is no key to disable, defer, or channel-pin updates.

`updaterBannerStagedAt` reads `{"version":"Claude 1.46388.3","stagedAt":1788543442357}`, i.e. the update was staged at 03:07 local and applied ten minutes later at 03:17. **The presence of a "banner staged" field suggests the intended behaviour is to offer the update, not to apply it unattended.**

## Expected behaviour

1. An update should never interrupt an in-flight session. Stage it and apply it on the next clean start — which is what a staged banner implies is already the intent.
2. If it must interrupt, it should ask, and "later" should be honoured.
3. There should be a setting to defer or disable automatic updates. There is none in the app config, and no OS-side equivalent, because the package is sideloaded rather than Store-managed.
4. The file-in-use dialog should not blame "another program" when the program holding the file is Claude.

## Steps to reproduce

1. Windows 11, Claude desktop installed from anthropic.com (sideloaded MSIX).
2. Start long-running work in the app and leave it unattended.
3. Wait for a release. On this machine the median wait is about a day.
4. The app stops its service, swaps its package, restarts, and the work is gone.

## Reproducing the evidence

```powershell
Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 6000 |
Where-Object { $_.Message -like "*Claude_*" } |
Select-Object TimeCreated, Id, LevelDisplayName, Message | Sort-Object TimeCreated

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='CoworkVMService'} -MaxEvents 400 |
Select-Object TimeCreated, Message | Sort-Object TimeCreated
```

## The ask

Give Windows users a way to defer an update, and never apply one over a running session.

No source file or test is named. First check whether the Windows desktop updater is represented in this claude-code repository, then reproduce the evidence with the supplied Get-WinEvent commands and inspect %APPDATA%\Claude\config.json. Done means updates no longer interrupt running sessions and users can defer them or choose an update setting.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.