[BUG] Claude Desktop (Windows MSIX): CoworkVMService blocks package update, causing Modified/NeedsRemediation corruption
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?
Claude Desktop on Windows repeatedly enters Modified, NeedsRemediation state after app
updates, refusing to launch. Repair via Settings also fails with "Another program is
currently using this file."
Root cause: CoworkVMService (app\resources\cowork-svc.exe) is registered as an
auto-start Windows service whose binary lives INSIDE the MSIX package directory
(C:\Program Files\WindowsApps\Claude_*\). It holds file handles there during normal use,
so when an update tries to delete the old package folder, deletion partially fails and
leaves the folder inconsistent with its manifest.
Killing the process doesn't help — parent is services.exe, so the SCM restarts it within
seconds. Set-Service and sc.exe config both fail with access denied even when elevated
(service DACL appears TrustedInstaller-only), so users cannot mitigate this through
supported means.
Observed 3 times across versions 1.25927.0.0, 1.30096.5.0, and 1.32352.1.0.
What Should Happen?
App updates should complete cleanly without corrupting the package, and Repair should
succeed. The service should not hold handles inside its own package directory during
package operations.
Error Messages/Logs
Dialog: C:\Program Files\WindowsApps\Claude_1.32352.1.0_...
"Another program is currently using this file."
PS> Get-AppxPackage -Name "*Claude*" | Format-List Name,PackageFullName,Status
Name : Claude
PackageFullName : Claude_1.30096.5.0_x64__pzs8sxrjxfjjc
Status : Modified, NeedsRemediation
PS> Get-CimInstance Win32_Service | Where { $_.PathName -like "*Claude_*" } | Format-List
Name : CoworkVMService
DisplayName : Claude
StartMode : Auto
State : Running
PathName : "C:\Program Files\WindowsApps\Claude_1.32352.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
PS> sc.exe config CoworkVMService start= demand
[SC] OpenService FAILED 5: Access is denied. # elevated session
Steps to Reproduce
- Install Claude Desktop on Windows 11 (MSIX package).
- Use the app normally so
CoworkVMServiceis running. - Allow an app update to install.
- Update fails to fully delete the old package folder.
- Launch Claude Desktop — "Can't open this app".
- Check status:
Get-AppxPackage -Name "Claude" | Format-List Status
-> Modified, NeedsRemediation
- Settings -> Apps -> Claude -> Repair
-> "Another program is currently using this file."
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
N/A — Claude Desktop 1.32352.1.0, not Claude Code
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
The app re-asserts Auto start on every launch
Setting the service to manual survives reboot, but is reverted by the app itself:
# App closed, service stopped:
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name Start -Value 3
Start-Sleep 30
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" | Select Start
# -> 3 (holds)
# Launch Claude Desktop, re-check:
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" | Select Start
# -> 2 (reverted to Auto)
Working workaround (no reinstall needed)
$pkg = (Get-AppxPackage -Name "Claude").InstallLocation
Start-Job { while($true){ Get-Process cowork-svc -EA SilentlyContinue | Stop-Process -Force; Start-Sleep -Milliseconds 200 } } | Out-Null
Start-Sleep 1
Add-AppxPackage -DisableDevelopmentMode -Register "$pkg\AppxManifest.xml"
Get-Job | Stop-Job; Get-Job | Remove-Job
Verified in Microsoft-Windows-AppXDeploymentServer/Operational:
Event 400 (register finished successfully), Event 617 (Clear=0x300, Clear=0x10000C00 —
corruption flags cleared), Event 10007 (package state enabled, 0x0).
Suggested fix
Move cowork-svc.exe outside the package directory, or register it as demand-start so it
isn't running during package operations.
Possibly the same root cause as #84333.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗