›_ Claude Code Issues
Claude Code Issues / #91988

[BUG] Windows MSIX: Claude Desktop stops launching until a full OS restart; activation succeeds but no window ever appears

Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 3 comments · opened Sep 4, 2026

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?

Summary

On Windows 11 with a Hebrew system locale, Claude Desktop (MSIX) stops launching after the machine has been running for a while, typically every morning. Windows reports activation as successful, a claude process exists, but no window is ever drawn and no application log is written. Only a full OS restart restores it. A normal shutdown and power on does not (Fast Startup is enabled by default). Repair, Reset, and reinstall all had no effect.
A second, related defect is included below: CoworkVMService cannot configure its own service recovery actions, so any crash of that service also requires a reboot.

Environment

| Item | Value |
|---|---|
| OS | Windows 11 |
| System locale | he-IL (Hebrew, Israel) |
| Package | Claude_1.44121.4.0_x64__pzs8sxrjxfjjc |
| Version | 1.44121.4.0 |
| Package status | Ok |
| SignatureKind | Developer |
| Install location | C:\Program Files\WindowsApps\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc |
| Service | CoworkVMService, Running, Automatic |
| VirtualMachinePlatform | Enabled (InstallState 1) |
| HypervisorPlatform | Disabled (InstallState 2) |

Steps to reproduce

  1. Use Claude Desktop normally during the day.
  2. Shut down or leave the machine overnight.
  3. In the morning, click the Claude icon.
  4. Nothing happens. No window, no error, no splash.

Expected

The application window opens, or an error is surfaced.

Actual

Nothing is drawn. Windows believes the activation succeeded.

Evidence collected

1. Windows reports activation success, repeatedly, with no window

Microsoft-Windows-TWinUI/Operational, Event ID 1621, repeated on every click:

Attempted activation of the app Claude_pzs8sxrjxfjjc!Claude.
Execution state: Attempted activation of the app, 0, The operation completed successfully.

2. A stale process persists and does not accept activation

Name      Id    StartTime
----      --    ---------
claude    14872 9/4/2026 7:08:13 AM

The process was still alive hours later with no window. Killing it and re-activating the package explicitly did not restore the window:

Get-Process *claude* | Stop-Process -Force
Start-Sleep 5
$p = Get-AppxPackage *claude*
Start-Process "shell:AppsFolder\$($p.PackageFamilyName)!$((Get-AppxPackageManifest $p).Package.Applications.Application.Id)"

3. No application log is ever written

Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache" -Recurse -Filter *.log

returns nothing, even immediately after launch attempts. The app appears to fail before it starts logging.

4. The VM service is healthy and waits forever for the app

C:\ProgramData\Claude\Logs\cowork-service.log:

Claude VM Service starting...
Waiting for configuration from app via 'configure' method...
[HCS] vmcompute.dll loaded successfully
[HCS] computecore.dll loaded successfully
[HCS] Procs initialized, HCS ready
[HCN] Initialized HCN API from computenetwork.dll
[HCN] EnumerateNetworks result: []
[Server] Named pipe server listening
Service ready. Listening on \\.\pipe\cowork-vm-service

The service is ready and the app never calls configure. This points at the app UI process, not the VM backend.

5. Secondary bug: the service cannot set its own recovery actions

Logged on every service start, and also surfaced in the Application event log under provider CoworkVMService:

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

Attempting to set them manually from an elevated administrator PowerShell also fails:

> sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/restart/10000/restart/30000
[SC] OpenService FAILED 5:
Access is denied.
> sc.exe qfailure CoworkVMService
SERVICE_NAME: CoworkVMService
        RESET_PERIOD (in seconds)    : 0

The service security descriptor denies SERVICE_CHANGE_CONFIG even to the local Administrators group, so recovery actions can never be configured, by the app or by the user. The practical result is that any crash of CoworkVMService requires a full machine reboot.

What was already tried, with no effect

  • Reinstalling Claude Desktop from the official download.
  • Windows Settings, Apps, Claude, Advanced options, Repair.
  • Windows Settings, Apps, Claude, Advanced options, Reset (local app data was 25.7 GB before the reset; the app itself is 413 MB).
  • Terminating all claude processes and re-activating the package by its AppUserModelId.
  • Verifying VirtualMachinePlatform is enabled.

The only thing that reliably works is a full Restart of Windows. Shutting down and powering on the next morning does not, which is consistent with Fast Startup preserving the broken state.

Suggested investigation

  1. Why does the app process survive without a window and refuse subsequent activations, instead of exiting or re-creating its window.
  2. Why nothing is written to %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache on a failed launch. A startup failure with zero logging leaves users with no way to self diagnose.
  3. Whether the Hebrew system locale (he-IL) is a factor. Similar Windows launch failures have been reported on non English system locales.
  4. The CoworkVMService security descriptor, so the service can actually configure its recovery actions. As shipped, the code path that sets them can never succeed.

What Should Happen?

The application window opens, or an error is surfaced.

Error Messages/Logs

Steps to Reproduce

  1. Use Claude Desktop normally during the day.
  2. Shut down or leave the machine overnight.
  3. In the morning, click the Claude icon.
  4. Nothing happens. No window, no error, no splash.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.44121.4.0 (MSIX package Claude_1.44121.4.0_x64__pzs8sxrjxfjjc)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

3 Comments

shimonga-png · 1 month ago

Still relevant, one week in with no response.

Update from my side: the app became launchable again only after a full package removal and clean reinstall. Repair, Reset and a plain reinstall all failed. What actually worked:

  1. Get-AppxPackage *Claude* | Remove-AppxPackage
  2. Manually deleted the leftover folder under %LOCALAPPDATA%\Packages
  3. Fresh install from claude.ai/download

That restores the app, but it is a workaround, not a fix. The underlying defects are unchanged:

  • A stale claude process survives with no window and refuses subsequent activations, while Windows reports activation as successful.
  • CoworkVMService cannot configure its own SCM recovery actions (access denied, even from an elevated admin shell), so once that service stops it never restarts itself and the app stays unlaunchable until a full OS restart.

Is there any update on this, or anything else you need from me such as logs or package state output? Happy to provide.

MN-LifaDigital · 16 days ago

I'm having similar issue, however I do get this in the windows log:
Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Adgang nægtet.

restarting OS is however NOT the solution, it happens every time I have rebooted, and I have to reinstall claude to get it running

optimonkdev · 15 days ago

Same issue here, with some additional diagnostics that may help.

Environment

  • Windows, Claude Desktop MSIX package Claude_2.16120.0.0_x64__pzs8sxrjxfjjc
  • Frequency: every day or every few days

Symptom
Claude Desktop closes by itself, then cannot be relaunched. Launching shows "Another program is currently using this file" (0x80070020). Reinstalling does not help. Only signing out of Windows and back in fixes it.

Findings

  1. The self-closing is the stealth auto-update. From main.log:
   [updater] Update downloaded and ready to install
   [stealth-update] Triggering stealth update after idle timeout
   beforeQuitForUpdate handler fired, going down for update
  1. Sysinternals Handle shows cowork-svc.exe holding the package folder open:
   cowork-svc.exe  pid: 1652  type: File  560: C:\Program Files\WindowsApps\Claude_2.16120.0.0_x64__pzs8sxrjxfjjc

CoworkVMService runs from ...\Claude_2.16120.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe with StartMode Auto.

  1. Stop-Service CoworkVMService -Force (elevated) releases the lock (Handle: "No matching handles found"), but the service comes back with a new PID shortly after.
  1. Set-Service CoworkVMService -StartupType Disabled fails even as administrator: "Access is denied". So the service cannot be kept down while the update is applied.
  1. After stopping the service and immediately relaunching via explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude, the error dialog no longer appears, but no window opens and no claude.exe process stays running.

Expected
The updater should stop CoworkVMService / cowork-svc.exe before quitting for an update, so the package can be replaced and the app can relaunch.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Windows & WSL problems, Crashes, hangs & freezes

Browse all Claude Code issue topics →