[BUG] Claude Desktop (Windows MSIX): CoworkVMService blocks package update, causing Modified/NeedsRemediation corruption

Status Closed — duplicate
Maintainer reply None cached
Activity 4 comments · opened Aug 18, 2026 · closed Aug 25, 2026

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

  1. Install Claude Desktop on Windows 11 (MSIX package).
  2. Use the app normally so CoworkVMService is running.
  3. Allow an app update to install.
  4. Update fails to fully delete the old package folder.
  5. Launch Claude Desktop — "Can't open this app".
  6. Check status:

Get-AppxPackage -Name "Claude" | Format-List Status
-> Modified, NeedsRemediation

  1. 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.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗