Claude Desktop (MSIX) fails to launch with "Another program is currently using this file" — requires full reboot

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 (MSIX / Microsoft Store, v1.44121.4.0) on Windows 11 Home (10.0.26200, 16 GB RAM) repeatedly fails to launch with "Another program is currently using this file" pointing at C:\Program Files\WindowsApps\Claude_*. Only a full reboot fixes it. Problem recurs every few days.

Diagnostic findings (all read-only, no changes made):

1. Rapid MSIX updates — 3 package versions deployed in 24 hours:

• Sep 2, 19:22 → 1.40609.1.0
• Sep 3, 07:34 → 1.44121.2.0
• Sep 3, 09:43 → 1.44121.4.0

1. CoworkVMService instability:

• Service reinstalled 7 times in one session (SCM Event ID 7045)
• Service crashed (Event ID 7034: "terminated unexpectedly") — also crashed on Sep 2
• Every start logs: "failed to configure SCM recovery actions: Access is denied" — cannot auto-restart after crash, requires reboot
• Each install immediately followed by StartType changed from auto start to disabled (Event 7040), then reinstalled again — a tight loop

1. 12 Claude.exe processes (Electron) + 1 cowork-svc hold handles to the package directory while MSIX background update tries to replace files → "file in use" error

1. AppXDeploymentServer logged: "There were 6 additional files that failed to be deleted under WindowsApps\Deleted" — cleanup pipeline partially jammed

1. Memory pressure (from main.log): app hit 1.4 GB RSS → webview became unresponsive → Sentry error → event loop stalled 588ms (system had only 585 MB free of 15.8 GB)

What Should Happen?

• MSIX updates should coordinate with the running app (stage update, apply on next launch, or gracefully restart)
• CoworkVMService should not require SCM permissions it cannot obtain under the MSIX sandbox
• The service install → disable → reinstall loop should not occur
• Service should stop cleanly when app exits (it does stop, but the crash/reinstall cycle during runtime is the issue)

Error Messages/Logs

## SCM Event Log — CoworkVMService crash + reinstall loop (Sep 3, 2026)

# Service crashed
TimeCreated: 03-09-2026 20:59:23
LevelDisplayName: Error
Id: 7034
Message: The Claude service terminated unexpectedly. It has done this 1 time(s).

# Service reinstalled 7 times in one session — each install immediately toggled to disabled
TimeCreated: 03-09-2026 20:59:34
Id: 7045 — Service installed (auto start)
Id: 7040 — StartType changed from auto start to disabled
# ...repeated at 20:55:38, 20:58:23, 20:59:34, 20:59:43, 09:43:50, 21:10:11

## CoworkVMService own log (C:\ProgramData\Claude\Logs\cowork-service.log)

Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
Warning: failed to disarm recovery actions for this stop: open service: Access is denied.

## AppXDeploymentServer (Event ID 493)

TimeCreated: 03-09-2026 21:10:35
Message: There were 6 additional files that failed to be deleted under the folder \\?\C:\Program Files\WindowsApps\Deleted.

## main.log — memory pressure + webview crash (Aug 21)

[warn] [CliGovernor] memory pressure (warning): would evict 0 idle session(s), 2 effective
[info] [process-memory] trigger=pressure tree_rss_sum=1476MB sys_free=585MB/15819MB
[info] Main webview is unresponsive, will kill and reload
[error] Sentry caught: { value: 'Main webview became unresponsive' }
[warn] [event-loop-stall] main process blocked for 588ms

Steps to Reproduce

1. Install Claude Desktop from Microsoft Store on Windows 11 Home
2. Leave the app running for extended periods
3. When a background MSIX auto-update arrives (3 updates in 24 hours observed), the update cannot replace files because 12+ Electron processes and CoworkVMService hold handles to the package directory
4. App enters broken state — closing and reopening fails with "Another program is currently using this file"
5. Only a full reboot resolves it

Workaround: After closing Claude Desktop, run in admin PowerShell:

Stop-Service CoworkVMService -Force

This releases the service's file handles, but does not help if the Electron processes have already blocked the update.

Diagnostic commands used (all read-only):

Get-AppxPackage -Name "*Claude*" | Select Name, Version, InstallLocation, Status
Get-Service CoworkVMService | Select Status, StartType
Get-Process Claude, cowork-svc -EA SilentlyContinue | Select Id, Name, StartTime, Path
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=(Get-Date).AddDays(-3)} -MaxEvents 100 | Where-Object { $_.Message -match 'Claude' }
Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 50

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.40609.1.0 (worked before rapid update cycle on Sep 2-3 2026)

Claude Code Version

2.1.258 (Claude Code) / 1.44121.4.0 (Claude Desktop MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_