Windows Store: Claude desktop fails to update due to CoworkVMService file lock and stuck WindowsApps\Deleted

Status Fixed / completed
Maintainer reply None cached
Activity 4 comments · opened Apr 10, 2026 · closed Apr 12, 2026

Environment

  • OS: Windows 11 Pro 10.0.26200
  • Claude Desktop: 1.1617.0.0 (Microsoft Store / MSIX package)
  • Package: Claude_1.1617.0.0_x64__pzs8sxrjxfjjc

Problem

Claude desktop installed from the Windows Store fails to update. The app closes for update (beforeQuitForUpdate handler fired, going down for update in main.log) but never restarts. Subsequent manual launch attempts fail with:

"Файл занят другой программой" (File is in use by another program) Path: C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__...

Root cause

Two issues combine to block the update:

1. CoworkVMService holds file locks on the package directory

The Windows service CoworkVMService runs cowork-svc.exe from inside the MSIX package folder (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe). When the app closes for update, the service keeps running and auto-restarts if the process is killed (Stop-Process). This locks the package files, preventing the Store from replacing them.

Stop-Service CoworkVMService -Force is required before the package can update, but the update mechanism does not do this automatically.

2. WindowsApps\Deleted cleanup failures (secondary)

Old package versions from other apps get stuck in C:\Program Files\WindowsApps\Deleted\ with recurring Event ID 493 errors ("Cannot delete files from Deleted directory") every 6 minutes in Microsoft-Windows-AppXDeploymentServer/Operational. While not Claude-specific, this further jams the Store update pipeline.

Expected behavior

The auto-updater should stop CoworkVMService before attempting to replace the package files, or the service should gracefully exit when the main app signals beforeQuitForUpdate.

Workaround

Migrated to standalone install via winget install Anthropic.Claude which uses Squirrel auto-updater and installs to %LOCALAPPDATA%\Programs\ — avoids WindowsApps entirely. AppData (%APPDATA%\Claude\) is preserved across migration.

Steps to reproduce (Store version)

  1. Install Claude desktop from Microsoft Store
  2. Use the app normally (CoworkVMService starts automatically)
  3. Wait for an auto-update trigger
  4. App closes with "going down for update" but CoworkVMService keeps running
  5. Update fails, app won't relaunch — "file in use" error

Manual fix sequence (if still on Store)

Stop-Service CoworkVMService -Force
Set-Service CoworkVMService -StartupType Disabled
Stop-Process -Name cowork-svc -Force
Stop-Process -Name chrome-native-host -Force
# Then update/reinstall from Store, or better: switch to winget

View original on GitHub ↗

4 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/45400
  2. https://github.com/anthropics/claude-code/issues/44668
  3. https://github.com/anthropics/claude-code/issues/42897

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

nBn4u · 6 months ago

Not a duplicate of #44668.

  • #44668 is about EXDEV cross-device rename failure causing an infinite retry loop that exhausts RAM and crashes the machine. Fix: fs.copyFile() fallback + retry backoff.
  • #46179 is about CoworkVMService holding file locks on the MSIX package directory, preventing Windows Store from replacing files during update. Fix: auto-updater must stop CoworkVMService before update.

Different root cause, different symptoms, different fix. The only shared element is CoworkVMService misbehaving on Windows MSIX installs.

nBn4u · 6 months ago

Closing as duplicate of #42776 which tracks the same root cause (orphaned process holds file lock → update blocked). Added the CoworkVMService details and fix suggestion there.

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.