claude-code - 💡(How to fix) Fix CoworkVMService AutoStart prevents Claude Desktop updates and launches on Windows (MSIX packaging bug)

Platform: Windows 11 Pro (10.0.26200) Claude Desktop version: 1.6608.0.0 (MSIX)

Summary

The MSIX package registers CoworkVMService with AutoStart (START_TYPE: 2 AUTO_START). This causes two separate failures:

Bug 1 — Updates fail with "Another program is currently using this file"

The service binary path is inside the WindowsApps package directory:

C:\Program Files\WindowsApps\Claude_1.6608.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Because the service is always running, it holds open file handles in the package directory. The MSIX updater cannot replace those files, so every update fails with the above error.

Bug 2 — Claude Desktop itself cannot launch after any update attempt

When CoworkVMService is running, it occupies the MSIX package's Windows Job Object. The AppX runtime then fails to create a Desktop AppX container for the main Claude.exe:

Event ID 215 (Microsoft-Windows-AppModel-Runtime/Admin):
0x80070020: Cannot create the Desktop AppX container for package
Claude_1.6608.0.0_x64__pzs8sxrjxfjjc because an error was encountered
converting the job.

This makes Claude Desktop completely unlaunchable until the service is manually stopped.

Root cause

CoworkVMService is a WIN32_PACKAGED_PROCESS service registered as AutoStart. It starts at boot before any user launches Claude Desktop, taking ownership of the package's Job Object. The MSIX update lifecycle does not stop the service before replacing package files.

Fix suggestion

Change CoworkVMService startup type to Manual (Demand). Claude Desktop should start the service on demand when needed, not at boot. Alternatively, move the service binary outside the WindowsApps package directory.

Workaround

The MSIX installation had to be completely removed and replaced with the Squirrel-based installer (Anthropic.Claude 1.6259.1 via winget), which auto-updated to 1.6608.0 and resolved both issues.