Skip to content

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

Description

@nBn4u

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

Activity

  1. github-actions commented on Apr 10, 2026

    @github-actions

    Found 3 possible duplicate issues:

    1. Windows: 'Another program is currently using this file' when clicking Relaunch to update #45400
    2. [BUG] Cowork Windows: EXDEV cross-device rename failure causes machine crashes on bundle update — affects all MSIX installs #44668
    3. Claude Code Cowork (Windows): stuck process after auto-update requires full reboot to relaunch #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

  2. nBn4u commented on Apr 12, 2026

    @nBn4u
    Author

    Not a duplicate of #44668.

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

  3. nBn4u commented on Apr 12, 2026

    @nBn4u
    Author

    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.

  4. github-actions commented on Apr 19, 2026

    @github-actions

    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.

  5. locked as resolved and limited conversation to collaborators on Apr 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions