[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)

[rnpacheco25-sudo]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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

• [BUG] Claude Desktop update fails with 0x80073CF6 when CoworkVMService is running (Windows) #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.
• [BUG] Claude Desktop 1.3109.0.0 fails to launch on Windows 11 Pro 25H2 — root-cause candidate identified (HCS Invalid JSON document) #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.
• [BUG] Claude Desktop fails to launch on Windows 11 25H2 (Build 26200) — CoworkVMService crashes during HCS DLL initialization #25914 — main.log is 0 bytes because the app crashes before logging starts. Same "process briefly created then container destroyed" signature.
• Claude Desktop 1.1.4088.0 — Multiple Critical Bugs on Windows 11 25H2 (Build 26200) #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 Claude Desktop 1.1.4088.0 — Multiple Critical Bugs on Windows 11 25H2 (Build 26200) #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

[robjarawan]

Cross-linking with #49655. This may be a related Windows AppX/MSIX container-lock symptom. In the #49655 repro, the visible error was also Another program is currently using this file, and the recoverable lock source was running Claude package processes under C:\Program Files\WindowsApps\Claude_* plus CoworkVMService.

Workaround/details: #49655 (comment)

This may not cover the orphaned Silo/Job Object case completely, but it is worth linking because both symptoms surface as AppX/WindowsApps sharing violations after update/relaunch.

[tazbdp]

Corroborating report from a second affected machine — and a new data point that discriminates between the two leading theories.

I hit this exact signature (208 + 215, 0x80070020, only sign-out/reboot recovers) on every in-place MSIX update, and ran a controlled test that I think narrows the root cause.

Environment

• Windows 11 Home
• MSIX install, package family Claude_pzs8sxrjxfjjc
• Most recent triggering transition: 1.11187.1.0 → 1.11847.5
• Companion service CoworkVMService (cowork-svc.exe)
• Reproduces on a fresh Windows install (not residual profile corruption)

Signature (identical to this issue)

Microsoft-Windows-AppModel-Runtime/Admin, every failed launch:

• 208: 0x80070020: Cannot create the process for package Claude_<ver>_x64__pzs8sxrjxfjjc ... [FinishPackageActivation]
• 215: 0x80070020: Cannot create the Desktop AppX container ... because an error was encountered converting the job.

Dialog: path in the title bar, body "Another program is currently using this file." claude.exe never spawns. Sign-out/login or reboot clears it every time.

NEW: a pre-update CoworkVMService mitigation does NOT prevent the wedge

The competing theory (#57221) is that the AutoStart CoworkVMService owns the package Job Object across the version transition, so neutralizing it before the update should help. I tested that directly:

Before clicking "Relaunch to update", as Administrator, with Claude still running:

1. Set CoworkVMService start type to Disabled (via SCM as NT AUTHORITY\SYSTEM, since the service DACL blocks Set-Service for Administrators)
2. Stop-Service CoworkVMService -Force
3. Killed cowork-svc.exe, parsecd, chrome-native-host
4. Verified no Claude/cowork processes remained (cold state)
5. Clicked "Relaunch to update", let it apply

Result: the post-update launch still wedged with the same 208/215 / 0x80070020, and a reboot was again required.

Since the service was disabled, stopped, and process-killed before the file swap, the "running service owns the Job Object" path is eliminated for this signature. That leaves the model described in this issue: the new version crashes during its first launch, kernel-side Silo/Job cleanup does not run, and the orphaned handle bound to the package family persists until the session is torn down (sign-out/reboot). The fix needs to be in the launch/crash path, not in service startup config.

Also ruled out on this machine (none prevented or recovered it)

Defender (real-time, BAFS, MAPS, sample submission, Tamper Protection all off); Smart App Control (Eval; CodeIntegrity/Operational empty during repro — no 3076/3077/3091/3092); SmartScreen for Apps (Off); ASR (none configured); Controlled Folder Access (Disabled); static file lock (File.Open FileShare.None succeeds, handle.exe finds no holders); Reset-AppxPackage; Add-AppxPackage -Register -ForceApplicationShutdown; restart of AppXSvc/ClipSVC/AppIDSvc/StateRepository/vmcompute; Explorer + RuntimeBroker + ApplicationFrameHost recycle; deleting the orphan prior-version WindowsApps folder; stopping CoworkVMService after the wedge.

Asks (same as OP, reinforced)

1. Guarantee Silo/Job cleanup when the launcher exits/crashes during startup, so a failed first launch after an update can't orphan a handle bound to the package family.
2. Provide a supported way to clear the orphaned handle without sign-out/reboot (or have activation detect and reset a stale Silo for the family before failing).
3. Fix the misleading "Another program is currently using this file" dialog — the failure is at the container/Silo layer, not a file lock.
4. Ship the chat-only fallback (Claude Desktop 1.1.4088.0 — Multiple Critical Bugs on Windows 11 25H2 (Build 26200) #28231) — if CoworkVMService/the VM fails, launching chat-only would avoid the crash that appears to trigger the leak.

Happy to provide ETW captures (AppModel-Runtime, AppXDeploymentServer/Operational, Hyper-V-Compute-Operational) of a failed post-update launch on request.