Claude Desktop (MSIX/Windows) fails to relaunch after auto-update; CoworkVMService ACL blocks admin mitigation

Status Open
Reported on v2.1.219
Maintainer reply None cached
Activity 0 comments · opened Aug 5, 2026

Description

Claude Desktop (Windows, MSIX/Microsoft Store install) intermittently fails to relaunch after auto-updating, requiring a full reinstall to recover.

Environment

  • OS: Windows 11 Pro
  • Install method: Microsoft Store (MSIX), package Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
  • Observed across at least 2 auto-updates (1.24012.9.0 -> 1.25927.0.0)

Evidence from %APPDATA%\Claude\logs\main.log

1) File lock conflicts during update:

[warn] [CCD] Could not remove old version 2.1.219 (in use?): EPERM: operation not permitted, unlink ...\claude-code\2.1.219\claude.exe
[error] [Chrome Extension MCP] Failed to copy native host binary: EBUSY: resource busy or locked, copyfile ...\chrome-native-host.exe -> ...\ChromeNativeHost\chrome-native-host.exe

2) Missing module in build 1.25927.0.0:

[warn] [watch-record] failed to subscribe to swift events Cannot find package @ant/claude-swift imported from ...app.asar\.vite\build\index.js  code: ERR_MODULE_NOT_FOUND

3) Prior crash (2026-08-01 22:33) where the internal Claude Code child process exits with code 1073807364, killing Electron Network Service:

[error] Session query error: Claude Code process exited with code 1073807364
[error] Network Service process gone (reason=killed, exitCode=1073807364) outside app quit -- main-process networking is broken until relaunch

4) C:\ProgramData\Claude\Logs\cowork-service.log shows the background CoworkVMService ("Claude" service, Automatic startup, runs independent of the app process) losing its RPC connection at the exact same timestamps as the crashes above:

[Server] Persistent RPC: connection ended: failed to read length: EOF

plus a recurring:

Warning: failed to open service for recovery config: Access is denied.

5) sc sdshow CoworkVMService shows the security descriptor grants no SERVICE_CHANGE_CONFIG right to Administrators or Authenticated Users -- only to the service's own virtual account. Even an elevated admin cannot change its Startup Type via services.msc (field is greyed out), so there is no user-side mitigation available.

Impact

The app auto-updates via MSIX while background processes (including the always-on CoworkVMService) may hold file handles open. The update can leave the package unable to relaunch until a full reinstall, with no supported way to reduce the always-on service's footprint to mitigate it.

Suggested fix

  • Ensure the updater fully quiesces/stops related processes (including CoworkVMService) before replacing in-use files, or retries gracefully instead of leaving the package broken.
  • Fix the packaging issue causing the missing @ant/claude-swift module.
  • Grant SERVICE_CHANGE_CONFIG to Administrators on CoworkVMService so users have a manual mitigation available

View original on GitHub ↗