[BUG] Windows MSIX: updater calls Remove with dev-mode-only PreserveApplicationData (fails 100%), then falls back to Add with ForceApplicationShutdown — force-killing the running app; can leave nothing installed

Preflight

• Searched existing issues (found #57371 re: the CoworkVMService being undisableable, and a Feb-2026 report of this same error string closed as not planned). This issue is about the update loop, which neither covers.
• Single bug report.
• Using the latest available package.

What's Wrong?

Claude Desktop's built-in updater (documented as checking "approximately every four hours") applies updates using a sequence that cannot succeed and that force-kills the running app.

Logged verbatim in Microsoft-Windows-AppXDeploymentServer/Operational, identically on every attempt:

603  Started deployment Remove operation ... Options PreserveApplicationData,RemoveForAllUsers
404  FAILED 0x80073CFA (ERROR_REMOVE_FAILED): "Windows cannot remove
     Claude_1.25927.0.0_x64__pzs8sxrjxfjjc because the PreserveApplicationData flag can
     only be used on a package that was deployed in development mode."

603  Started deployment Remove operation ... Options PreserveApplicationData
404  FAILED 0x80073CFA: identical error.

603  Started deployment Add operation ... Claude-<random>.msix
     Options ForceApplicationShutdownOption, ForceUpdateFromAnyVersion
854  uri: file:///C:/Users/<user>/AppData/Local/Temp/Claude-<random>.msix
400/649  Add COMPLETES.

Defect 1 — the Remove can never succeed. RemovalOptions.PreserveApplicationData (4096) is documented as applying only to packages deployed with DeploymentOptions.DevelopmentMode; otherwise RemovePackageAsync returns E_INVALIDARG. This package reports IsDevelopmentMode: False, so both Removes fail 100% of the time. This is parameter validation, not a file lock — a genuine in-use failure would be 0x80073D02 ERROR_PACKAGES_IN_USE.

Defect 2 — the fallback kills the user's session. After the Removes fail, the updater issues Add with ForceApplicationShutdownOption (DeploymentOptions 1), which force-shuts-down the package's processes with no prompt and no chance to save. Users experience this as the app crashing or vanishing mid-task.

Defect 3 — it can leave nothing installed. The package ships service CoworkVMService (StartupType="auto", StartAccount="localSystem") whose image is inside the package at app\resources\cowork-svc.exe. When it is running, the fallback Add also fails:

00:04:05  462 FAILED 0x80070020 (ERROR_SHARING_VIOLATION): Creating file
     ...\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe failed.
00:04:06  401 FAILED 0x80070020
00:04:06  404 FAILED 0x80073CF9      <-- install failed; NO app installed
00:04:28  603 RegisterByPackageFullName (RepairAppRegistrationOption)

The version never changes — 1.25927.0.0 → 1.25927.0.0. These are the same build re-added over itself, not upgrades.

What Should Happen?

Updating should not remove the package. Adding a newer MSIX updates in place and preserves app data automatically.

1. Drop PreserveApplicationData — invalid here, and its guaranteed failure is what forces the destructive fallback.
2. Don't remove before adding.
3. Stop the packaged service as part of deployment so its executable isn't held open.
4. Don't use ForceApplicationShutdown on a consumer app — prompt, or defer until exit.
5. If the Add fails, restore the previous package rather than leaving the machine with nothing, and surface an error. Currently nothing appears in the UI, Crashpad reports/ is empty, and Reliability Monitor logs nothing, because a deployment force-shutdown is not a crash.

Steps to Reproduce

1. Install Claude Desktop on Windows from the MSIX endpoint.
2. Confirm CoworkVMService is Running (StartupType auto).
3. Open Claude and start working.
4. Wait for the ~4-hourly update check (or run the installer).
5. Observe the two 0x80073CFA Remove failures naming PreserveApplicationData, then an Add with ForceApplicationShutdownOption.
6. The running session is terminated with no prompt.
7. If the service held cowork-svc.exe, the Add also fails (0x80070020 → 0x80073CF9) and no Claude remains installed.

Impact

Observed 8 package-removal operations on 5 Aug 2026 and 8 on 6 Aug 2026 on one machine, with 4–5 manual reinstalls and repeated loss of in-progress work. Because a force-kill looks like a crash, the natural response is to reinstall — which force-kills the app again. The cycle is self-sustaining.

Why users can't mitigate this

• The service's start type cannot be changed even from an elevated admin prompt: its DACL grants SERVICE_CHANGE_CONFIG only to NT SERVICE\AppXSvc; Administrators aren't in the DACL. sc config / Set-Service return Access is denied. (Same finding as #57371.)
• Stopping the service doesn't stay stopped — auto start plus a demand-start trigger on \pipe\cowork-vm-service.
• Stopping the service doesn't fix the update either; the Remove fails on parameter validation regardless.
• Store update settings don't apply — the package is SignatureKind: Developer, not Store-managed. Set-AppxPackageAutoUpdateSettings doesn't exist on this build.

The only effective lever is the documented policy HKLM\SOFTWARE\Policies\Claude\disableAutoUpdates=1, which requires admin and disables updates wholesale.

Is this a regression?

I don't know — the identical error string was reported in February 2026 against an older package and closed as not planned, so this has persisted across at least six months and multiple versions.

Environment

• Claude Desktop package: Claude_1.25927.0.0_x64__pzs8sxrjxfjjc (MSIX), SignatureKind: Developer
• Claude Code version: 2.1.221
• Platform: Anthropic API
• Operating System: Windows 10 Home 10.0.19045 (x64, 15.9 GB RAM)
• Terminal/Shell: PowerShell 5.1 / Git Bash
• Deployment policy: AllowAllTrustedApps=0, AllowDevelopmentWithoutDevLicense=1

Related

• #57371 — undisableable CoworkVMService. Same service, different problem (that one asks for a way to turn it off; this one is the update loop).

Not established

What first breaks the app registration (Windows ran RepairAppRegistrationOption before two of the reinstalls); whether this reproduces on Windows 11; whether disableAutoUpdates is honoured on a consumer, non-MDM install.