[BUG] Claude Desktop fails to launch on Windows — orphaned Silo / Job Object after app crash, only logoff or reboot recovers (HRESULT 0x80070020 in AppModel-Runtime EventID 215/208)

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 on Windows enters a state where launch fails with the user-facing message:

"Há um outro programa usando este arquivo no momento." (English equivalent: "Another program is currently using this file.")

referencing C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\....

The message is misleading — there is no actual file lock in the install directory. The real failure is in the AppX/Desktop Bridge container layer.

Real diagnosis (from Event Logs)

Channel Microsoft-Windows-AppModel-Runtime/Admin shows two correlated events on every failed launch:

• Event ID 215: 0x80070020: cannot create the Desktop AppX container for package Claude_<full>_x64__pzs8sxrjxfjjc due to an error converting the job
• Event ID 208: 0x80070020: cannot create the process for package Claude_<full>_x64__pzs8sxrjxfjjc due to an error setting up the runtime. [LaunchProcess]

HRESULT 0x80070020 = ERROR_SHARING_VIOLATION, surfacing during the Job Object → Silo conversion (the Win32 container layer that backs Desktop Bridge / AppX-packaged Win32 apps).

Hypotheses ruled out

• ❌ No userspace process has modules loaded from the Claude install directory at the time of failure
• ❌ No file in the install directory has an exclusive lock (verified via Sysinternals handle.exe and Process Explorer)
• ❌ Other AppX apps (Notepad, OneDriveSync, Microsoft Store apps) successfully create Desktop AppX containers in the same time window — the issue is specific to the Claude package
• ❌ HCS (Host Compute Service, used by cowork-svc.exe for the Cowork sandbox VM) has no orphaned compute systems (hcsdiag list returns clean)
• ❌ Reset-AppxPackage with admin privileges does NOT recover
• ❌ Add-AppxPackage -Register (re-register manifest) does NOT recover
• ❌ Restarting AppXSvc, ClipSVC, AppReadiness, vmcompute, CoworkVMService does NOT recover
• ❌ The Claude desktop process is briefly created and added to the container, then the container is destroyed immediately — suggesting an app crash during startup that doesn't propagate cleanup back through the Silo

Only known workaround

Logoff + Login (or full reboot). This clears the orphaned handle in the user-session. Service restarts and AppX package resets do not clean it up.

This matches the kernel-level lock pattern documented in #49655 (Helium hive locks held by cowork-svc.exe that survive service stop), but surfaces at a different layer (Silo/Job conversion at AppX activation time, not MSIX deployment time).

What Should Happen?

The Claude Desktop launch path should not leave an orphaned Silo/Job handle when it crashes during startup. Cleanup should be guaranteed via SEH / signal handlers / RAII-equivalent in the launcher process.

If CoworkVMService initialization fails, the app should fall back to chat-only mode (already requested in #28231) instead of crashing the entire activation.

The user-facing message ("Há um outro programa usando este arquivo no momento" / "Another program is using this file") is wrong and should be improved — there is no file lock; the failure is at the container layer.

Error Messages/Logs

Microsoft-Windows-AppModel-Runtime/Admin

Event ID 215:
0x80070020: cannot create the Desktop AppX container for package Claude_<full>_x64__pzs8sxrjxfjjc due to an error converting the job

Event ID 208:
0x80070020: cannot create the process for package Claude_<full>_x64__pzs8sxrjxfjjc due to an error setting up the runtime. [LaunchProcess]

HRESULT 0x80070020 = ERROR_SHARING_VIOLATION

User-facing dialog (Portuguese Windows):
"Há um outro programa usando este arquivo no momento."
referencing C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\...

Full event log dumps, Get-AppxPackage output, service states, HCS/HNS state, and Claude logs are included in the attached claude-diag-<timestamp>.zip.

Steps to Reproduce

Not deterministic on demand. Observed pattern:

1. Use Claude Desktop normally for a session.
2. App crashes (any cause — observed after Cowork session, after sleep/wake, after Windows update notification).
3. Attempt to relaunch from Start menu / taskbar.
4. Error dialog appears: "Há um outro programa usando este arquivo no momento" referencing C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\....
5. Event Viewer → Microsoft-Windows-AppModel-Runtime/Admin shows EventID 215 + 208 with HRESULT 0x80070020.

Already attempted (none recover without logoff/reboot)

• Reset-AppxPackage Claude_pzs8sxrjxfjjc (elevated)
• Get-AppxPackage Claude_pzs8sxrjxfjjc | Reset-AppxPackage
• Add-AppxPackage -Register "<install>\AppxManifest.xml" -DisableDevelopmentMode
• Restart-Service AppXSvc, ClipSVC, AppReadiness, vmcompute, CoworkVMService (in various orders)
• taskkill on all claude*, cowork-svc*, parsecd*, chrome-native-host* processes
• Verified hcsdiag list is clean (no orphan compute systems)
• Verified handle.exe reports no userspace handles into the install dir

Only logoff + login (or reboot) recovers the launch path.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is Claude Desktop on Windows, not Claude Code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Component involved

Claude Desktop bundles a custom Windows service CoworkVMService (executable: cowork-svc.exe) that creates a sandbox Linux VM via HCS (same API used by Hyper-V / WSL2 / Windows Sandbox). The smol-bin.x64.vhdx file in the install directory is that VM's disk.

Suspected root cause: when the Claude desktop process crashes during startup, the kernel-side Silo/Job cleanup does not run, leaving an orphaned handle in the user session. AppX activation for subsequent launch attempts hits ERROR_SHARING_VIOLATION when trying to convert a fresh Job Object into a Silo bound to the same package family in the same session.

Relationship to other issues

• #49655 — 0x80073CF6 ERROR_PACKAGES_IN_USE from kernel locks held by cowork-svc.exe on Helium hive files; "only full reboot releases the kernel-level locks". Same cleanup-on-crash defect, observed at MSIX-deployment layer instead of activation layer.
• #50825 — Launch failure on Windows 11 Pro 25H2 with v1.3109.0.0; HCS reports Invalid JSON document '$' on VM shutdown. Subsequent CoworkVMService starts succeed but Claude Desktop still fails to launch — service is healthy, app-to-service handoff or stored state is wedged.
• #25914 — main.log is 0 bytes because the app crashes before logging starts. Same "process briefly created then container destroyed" signature.
• #28231 — "No graceful fallback when CoworkVMService fails — the entire app crashes rather than launching in chat-only mode." Suggests the app's failure path is itself the trigger for the Silo leak.

Already attempted

• Reset-AppxPackage Claude_pzs8sxrjxfjjc (elevated)
• Get-AppxPackage Claude_pzs8sxrjxfjjc | Reset-AppxPackage
• Add-AppxPackage -Register "<install>\AppxManifest.xml" -DisableDevelopmentMode
• Restart-Service AppXSvc, ClipSVC, AppReadiness, vmcompute, CoworkVMService (in various orders)
• taskkill on all claude*, cowork-svc*, parsecd*, chrome-native-host* processes
• Verified hcsdiag list is clean (no orphan compute systems)
• Verified handle.exe reports no userspace handles into the install dir

Only logoff + login (or reboot) recovers the launch path.

Asks of engineering

1. Confirm whether the Silo/Job cleanup-on-crash defect is the root cause.
2. Provide a way to clear the orphaned handle without logoff/reboot (e.g., a documented PowerShell sequence or a flag in the app).
3. Improve the user-facing error message — the current "another program is using this file" is actively misleading and sends users on a wild goose chase looking for file locks that don't exist.
4. Consider the chat-only fallback already requested in #28231 — it would also avoid this leak path.

Happy to provide additional traces (ETW for AppXDeploymentServer or Microsoft-Windows-AppModel-Runtime, WPR captures of a failed launch) on request.

Environment

• OS: Windows 11 Pro <build>
• Claude Desktop: Claude_<version>_x64__pzs8sxrjxfjjc (MSIX, installed via claude.ai/download → MSIX bootstrapper)
• Diagnostic ZIP: claude-diag-<timestamp>.zip (attached) — includes EventLog dumps for AppModel-Runtime/Admin, AppXDeploymentServer/Operational, Hyper-V-Compute-Operational, full Get-AppxPackage output, service states, HCS/HNS state, and Claude logs.

Note on this template

This bug report concerns Claude Desktop on Windows, not Claude Code. The closest matching repo for filing the report appears to be this one. The "Claude Code Version" field has been filled with N/A accordingly, and the OS / Platform fields have been set to the closest available values.

claude-diag-20260425-093813.zip