[BUG]

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?

Additional data point: Modified, NeedsRemediation appears on a clean install immediately after first launch — with zero package file modifications

Different machine, same symptom. Sharing negative results since they may narrow the search.

Environment

• Windows 11, English username, system drive C:
• Claude Desktop 1.28929.0.0 → auto-updated to 1.30096.1.0 during testing
• MSIX, per-user install (Get-AppxProvisionedPackage returns empty)
• SignatureKind: Developer, IsDevelopmentMode: False

Symptom
Same as OP: app crashes after running for a while, Windows then demands
"Advanced options → Repair" or reinstall. Repair works temporarily; issue returns.

Ruled out by testing (all negative)

• NTFS drive compression on C: — not enabled
• Non-ASCII characters in username path — username is ASCII
• Package on non-system volume — installed on C:
• Antivirus interference — Get-MpThreatDetection shows no Claude-related entries; Defender only, no third-party AV
• System file corruption — sfc /scannow and DISM both clean
• Virtualization stack — VirtualMachinePlatform Enabled; vmcompute and hns both Running
• Disk space — 41 GB free
• AppXDeploymentServer/Operational log — every Add/Register/Repair operation completed with 0x0. Not a single Error or Warning event related to Claude.

The main finding

After a full Remove-AppxPackage + reboot + clean reinstall with admin/UAC:

What Should Happen?

Claude Desktop should remain running without Windows placing the MSIX package
into a state that requires "Advanced options → Repair" or reinstallation.

Specifically:

1. Package integrity state should stay Ok after launch. On a clean install

with admin/UAC, Get-AppxPackage *Claude* | Select Status returns Ok, then
flips to Modified, NeedsRemediation after the app is launched once — while
every file under the package install directory still carries the original
install timestamp. If nothing in the package is actually modified, Windows
should not be reporting it as modified.

1. If Modified, NeedsRemediation is expected and benign for this package, that

should be documented. As it stands it reads as a fault indicator and leads
users into a long dead-end investigation.

1. When the app does fail, it should surface a clear diagnostic rather than

leaving Windows to show a generic "reinstall the application" message with no
corresponding error in the AppXDeploymentServer/Operational log.

1. Repair should actually restore a working state. In this case it completed

successfully (logged as RepairAppRegistrationOption with result 0x0) but the
app still failed to launch afterwards, and a full uninstall and reinstall was
required.

Error Messages/Logs

Windows dialog on launch:

  There's a problem with Claude. Reinstall the application from its original
  install location or contact your administrator.

Earlier variant of the same dialog:

  You'll need to go to advanced options for Claude and select Repair. If you're
  still having issues with it, reinstall this app or contact your administrator.

---

Package state — flips after first launch on a clean install:

  PS> Get-AppxPackage *Claude* | Select Version, Status

  Version      Status
  -------      ------
  1.30096.1.0  Ok                            <- immediately after clean install
  1.30096.1.0  Modified, NeedsRemediation    <- after launching the app once

---

Remove-AppxPackage failure (before the flag was dropped):

  Remove-AppxPackage : Deployment failed with HRESULT: 0x80073CFA, Removal failed.
  Please contact your software vendor.
  Windows cannot remove Claude_1.30096.1.0_x64__pzs8sxrjxfjjc because the
  PreserveApplicationData flag can only be used on a package that was deployed
  in development mode.

---

Service state — CoworkVMService stopped, and its recovery config is empty:

  PS> Get-Service CoworkVMService
  Status   Name              DisplayName
  ------   ----              -----------
  Stopped  CoworkVMService   Claude

  PS> sc.exe qfailure CoworkVMService
  SERVICE_NAME: CoworkVMService
          RESET_PERIOD (in seconds)    : 0
          REBOOT_MESSAGE               :
          COMMAND_LINE                 :

  PS> sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/...
  [SC] OpenService FAILED 5:
  Access is denied.

---

Package file timestamps — no file written after install, despite Modified state:

  PS> Get-ChildItem "C:\Program Files\WindowsApps\Claude_1.30096.1.0_x64__pzs8sxrjxfjjc" `
        -Recurse -File | Sort LastWriteTime -Desc | Select -First 10 LastWriteTime, Name

  LastWriteTime        Name
  -------------        ----
  8/15/2026 3:32:04 AM resources.scale-200.pri
  8/15/2026 3:32:04 AM resources.pri
  8/15/2026 3:32:04 AM priconfig.xml
  8/15/2026 3:32:04 AM Wide310x150Logo.scale-200.png
  8/15/2026 3:32:04 AM Square44x44Logo.targetsize-24_altform-unplated.png
  ... (all remaining files share the identical install timestamp)

---

AppXDeploymentServer/Operational — NO errors or warnings. Every operation
succeeded, including the Repair that did not fix the app:

  Id 603:  Started deployment RegisterByPackageFullName operation ...
           Options RepairAppRegistrationOption and 0
  Id 400:  Deployment Register operation with target volume C: ... finished successfully
  Id 10001: Finished servicing package ... Setting the package state to enabled returned with 0x0

Notable: the app produces no error output of its own. The only signal is the
Windows shell dialog.

Steps to Reproduce

Environment: Windows 11, ASCII username, system drive C:, per-user MSIX install
(Get-AppxProvisionedPackage returns empty), Claude Desktop 1.30096.1.0.
No third-party antivirus. Verified clean: sfc /scannow, DISM, NTFS compression
off, vmcompute + hns Running, 41 GB free.

--- Part A: reproduce the package state flip (deterministic on this machine) ---

1. Fully remove any existing install, from an elevated Windows PowerShell 5.1:

Get-Process claude,Cowork,Anthropic* -EA SilentlyContinue | Stop-Process -Force
Stop-Service CoworkVMService -Force -EA SilentlyContinue
Get-AppxPackage Claude | Remove-AppxPackage
Get-AppxPackage Claude # must return empty

1. Reboot.

1. Install from claude.ai/download, accepting the UAC prompt.

1. WITHOUT launching the app, check package state:

Get-AppxPackage Claude | Select Version, Status
-> Status: Ok

1. Record every package file timestamp for later comparison:

Get-ChildItem "C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc" `
-Recurse -File | Sort LastWriteTime -Desc | Select -First 20 LastWriteTime, Name

1. Launch Claude Desktop once. Sign in. Close it.

1. Check package state again:

Get-AppxPackage Claude | Select Version, Status
-> Status: Modified, NeedsRemediation

1. Re-run the command from step 5.

-> Every file still carries the original install timestamp, to the second.
Nothing was written. The state changed without any file changing.

Steps 4-8 reproduced on both 1.28929.0.0 and 1.30096.1.0 on this machine.

--- Part B: the actual crash (timing-dependent, not deterministic) ---

1. Use the app normally. After a period of use (minutes to hours, no consistent

trigger identified) the app stops.

1. Relaunch. Windows shows:

"There's a problem with Claude. Reinstall the application from its original
install location or contact your administrator."

1. Settings > Apps > Installed apps > Claude > Advanced options > Repair.

Repair reports success and logs cleanly (Event ID 603 with
RepairAppRegistrationOption, then 400 "finished successfully", all 0x0).

1. Relaunch. On this machine the app still failed after Repair, and a full

uninstall + reboot + reinstall (steps 1-3) was required to recover.

1. Check the deployment log — it contains no Error or Warning for Claude at any

point in the above:

Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 5000 |
Where-Object { $_.Message -like "Claude" -and $_.LevelDisplayName -in "Error","Warning" }

--- Notes for whoever picks this up ---

• Part A is the reliable repro and takes ~10 minutes. Part B requires waiting for

the crash and is what actually breaks the install.

• I could not establish that Part A causes Part B. They may be unrelated. Part A

is included because it is reproducible and currently indistinguishable from a
fault, which sends users down a long dead-end.

• Also observed, likely a separate issue: vmcompute and hns shipped as Manual

startup on this machine, so they were not running after reboot. Setting both to
Automatic is a real fix independent of this bug.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.30096.1.0

Claude Code Version

1.30096.1.0

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

claude Desktop App