[BUG] [BUG] Claude Desktop MSIX package repeatedly enters Modified, NeedsRemediation after opening additional Cowork sessions; installer cannot repair it (0x80073CFA → 0x80073CF9)
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?
On Windows 10 22H2, the Claude Desktop MSIX package repeatedly transitions toStatus: Modified, NeedsRemediation while the app is in normal use. Once this
happens, Windows refuses to launch the app ("Не удается открыть приложение /
There's a problem with Claude. Reinstall the app from its original install
location"), and the bundled installer cannot repair or replace the package —
it only succeeds if the broken package is first removed manually withRemove-AppxPackage.
This happened three times in one day, each time within ~20–40 minutes of a clean
install. In the two occurrences where the moment of failure was observed, it
coincided with opening an additional parallel Cowork session (the 2nd session
in one case, the 3rd in the other).
What Should Happen?
The MSIX package should not be modified in place at runtime. Normal use of the
app — including opening several parallel Cowork sessions — should not cause
Windows to flag the package as Modified, NeedsRemediation.
When a package does end up in NeedsRemediation state, the bundled installer
should be able to repair or replace it. Currently its data-preserving removal is
rejected by Windows (0x80073CFA, requires developer mode), it falls back to an
in-place update, and that fails with 0x80073CF9. Recovery requires a manualRemove-AppxPackage first.
CoworkVMService should be removable by an administrator. It currently survives
package removal and its security descriptor grants delete rights only to the
service's own SID, so neither the installer nor an elevated admin shell can
delete or reconfigure it.
Error Messages/Logs
Removing conflicting CoworkVMService...
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
Checking for existing Claude MSIX packages...
Removing: Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude_1.34493.1.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
Installing via AddPackage (current-user)...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
Steps to Reproduce
[BUG] Claude Desktop MSIX package repeatedly enters Modified, NeedsRemediation after opening additional Cowork sessions; installer cannot repair it (0x80073CFA → 0x80073CF9)
Summary
On Windows 10 22H2, the Claude Desktop MSIX package repeatedly transitions toStatus: Modified, NeedsRemediation while the app is in normal use. Once this
happens, Windows refuses to launch the app ("Не удается открыть приложение /
There's a problem with Claude. Reinstall the app from its original install
location"), and the bundled installer cannot repair or replace the package —
it only succeeds if the broken package is first removed manually withRemove-AppxPackage.
This happened three times in one day, each time within ~20–40 minutes of a clean
install. In the two occurrences where the moment of failure was observed, it
coincided with opening an additional parallel Cowork session (the 2nd session
in one case, the 3rd in the other).
Environment
| Item | Value |
| --- | --- |
| OS | Windows 10 Pro 22H2, build 10.0.19045, x64 |
| DISM image version | 10.0.19045.6456 |
| Claude Desktop | MSIX 1.34493.1.0, family Claude_pzs8sxrjxfjjc |
| Installer bootstrapper | 255293a41a25d54c5177aa9614fb4cd620e70b78 |
| Claude Code CLI | 2.1.245 (installed separately, works fine) |
| Plan | Max |
| Sideloading | enabled |
| S Mode | false |
| Free space on C: | 27.7 GB |
Issue 1 — package spontaneously becomes Modified, NeedsRemediation
After a successful install, the app launches and works. After some use it stops
launching, and Windows shows the generic app-package error dialog. At that point:
Name : Claude
Version : 1.34493.1.0
Status : Modified, NeedsRemediation
No deployment events are logged for the package at all. Searching the last
1000 events in Microsoft-Windows-AppXDeployment-Server/Operational forClaude / pzs8sxrjxfjjc returns nothing:
Get-WinEvent -LogName "Microsoft-Windows-AppXDeployment-Server/Operational" -MaxEvents 1000 |
Where-Object { $_.Message -like "*laude*" -or $_.Message -like "*pzs8sxrjxfjjc*" }
# (no output)
So the package contents are diverging from the manifest outside the
deployment subsystem — i.e. at runtime, not via any install/update operation.
Re-registering from the manifest completes without error but does not clear the
status:
Get-AppxPackage -Name Claude | ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"
}
# completes silently; Status remains Modified, NeedsRemediation
(Reset-AppxPackage is not available on Windows 10.)
Observed trigger
Both times the moment of breakage was noticed, it was on opening an additional
parallel Cowork session with a local folder attached — once on the 2nd session,
once on the 3rd. Sessions were freshly created, not resumed. The app had been
working normally with fewer sessions open.
This is an observation, not a confirmed cause — but it is the only pattern that
survived elimination (see below).
Issue 2 — installer cannot replace an existing package
The installer's data-preserving removal is rejected by Windows, and its fallback
path then fails. From ClaudeSetup.log:
Removing conflicting CoworkVMService...
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
Checking for existing Claude MSIX packages...
Removing: Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude_1.34493.1.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
Removing (user): Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude_1.34493.1.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
Installing MSIX: ...
Standard install (not split-account), using AddPackage
Installing via AddPackage (current-user)...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
0x80073CF6 (ERROR_INSTALL_REGISTRATION_FAILURE) was also seen once on the
same path.
Correlation across four installer runs in one day
| Time | Existing package found | Result |
| --- | --- | --- |
| 16:22 | no (manually removed first) | completed successfully |
| 17:44 | yes → 0x80073CFA → in-place update | completed successfully |
| 18:12 | no (manually removed first) | completed successfully |
| 18:33 | yes → 0x80073CFA → in-place update | failed, 0x80073CF9 |
Every run that started from a clean state succeeded. The in-place-update fallback
is unreliable. The practical workaround is:
Get-Process *claude* -ErrorAction SilentlyContinue | Stop-Process -Force
Stop-Service CoworkVMService -Force
Get-AppxPackage -Name Claude | Remove-AppxPackage
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force
# verify Get-AppxPackage -Name Claude returns nothing, then run the installer
Note the log line says the rejection requires developer mode. Developer Mode
was subsequently enabled; the failure in Issue 1 still recurs, so this affects
recovery only, not the underlying breakage.
Issue 3 — orphaned CoworkVMService cannot be removed by an administrator
The service survives package removal and keeps running with the app uninstalled.
The installer cannot delete it (Access is denied), and neither can an elevated
64-bit administrator shell:
sc.exe delete CoworkVMService → [SC] OpenService: error 5, Access is denied
Set-Service CoworkVMService -StartupType Disabled → Access is denied
Its security descriptor grants delete/write-DAC only to the service's own SID;BUILTIN\Administrators has no ACE at all:
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
Stop-Service works (Authenticated Users have SW), but the service cannot be
deleted or reconfigured through the SCM. The only way to disable it was writingStart = 4 directly toHKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService.
An orphaned service that no administrator can remove is a problem in its own
right, and it is also what blocks the installer's cleanup path.
Additionally — leftover package data folder cannot be renamed
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc survives uninstall and cannot be
renamed even after takeown + icacls grant full ownership (rename is refused;
delete works only once chrome-native-host.exe is not held by a running Chrome).
This blocked reinstall until handled manually.
Causes ruled out
| Hypothesis | How it was excluded |
| --- | --- |
| Antivirus quarantining package files | Avast was installed and has been uninstalled; Defender now AMRunningMode: Normal; Get-MpThreatDetection empty; breakage recurred afterwards |
| Failed background auto-update | No deployment events for the package at all (1000 events checked); version never changed from 1.34493.1.0 |
| Disk space | 27.7 GB free on C: |
| System file / component store corruption | sfc /scannow found and repaired files; DISM /RestoreHealth succeeded; second sfc clean — breakage still recurred afterwards |
| Large or pathological workspace folder | Attached folders are 11 MB and 850 MB / 760 files total |
| Stale Start menu shortcut | App located via Start menu search; package status confirmed broken independently via Get-AppxPackage |
Steps to reproduce
- Windows 10 22H2 x64, clean install of Claude Desktop (package removed
manually beforehand so the install succeeds).
- Launch the app, sign in.
- Create a Cowork session and attach a local folder.
- Create a second, then a third parallel Cowork session with their own folders.
- The app stops launching;
Get-AppxPackage -Name Claudereports
Modified, NeedsRemediation.
Expected
The package should not be modified in place at runtime, and the installer should
be able to repair or replace a package in NeedsRemediation state without manualRemove-AppxPackage.
Attachments
ClaudeSetup.log (covers six installer runs, including all failures above).
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
unknown
Claude Code Version
2.1.245
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell