[BUG] Claude Desktop 1.34493.1.0 (Windows) exits after ~7s without connecting to CoworkVMService — no crash event, no main.log

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 launches, creates its AppX container, and exits on its own after ~7 seconds. Windows then shows the generic "go to advanced options and select Repair" dialog. Earlier in the sequence the app rendered a window and reached the Cloudflare check on the login screen before exiting; it now exits before the window is usable.

The distinguishing detail: the MSIX package is verifiably healthy and the system has been fully validated, yet the main process never opens the named pipe to CoworkVMService. The service starts correctly every time and is stopped only because the app went away.

This matches #46123 (closed as duplicate, with no linked target), but that report was on 1.1617.0.0 and did not check package state or WindowsApps ACLs.

Ruled out on this machine, all negative:

• Package state was Modified, NeedsRemediation. Reset-AppxPackage and Settings → Repair both failed every time, matching #82967. Full Remove-AppxPackage -AllUsers + provisioned-package removal + reboot + fresh install cleared the state but did not change the behaviour.
• C:\Program Files\WindowsApps owner had been changed to BUILTIN\Administrators; restored to NT SERVICE\TrustedInstaller with correct SID-based ACEs. AppXDeploymentServer had been logging Trying to repair ACLs ... Register next time should succeed on every single registration; that stopped after the fix. No behaviour change.
• sfc /scannow found and repaired corruption; DISM /Online /Cleanup-Image /RestoreHealth completed successfully.
• VirtualMachinePlatform: Enabled.
• fltmc filters: no third-party filter drivers — Microsoft only (WdFilter, bindflt, wcifs, UnionFS). AV interference is not possible here.
• No VPN or proxy. claude.ai works normally in a browser on the same machine.
• No leftover processes after exit (claude, cowork).
• Earlier AppXDeploymentServer history shows repeated error 0x12C (oplock not granted) deleting app\icudtl.dat and app\v8_context_snapshot.bin from WindowsApps\Deleted, plus a DeferRegistrationWhenPackagesAreInUse update on 18.08 that only registered ~54 minutes later. Plausibly how the package state got corrupted in the first place.

ClaudeSetup.log shows a clean install path: signature verified, AddPackage succeeds, exit code 0. Note it completes in ~4 s for a 247 MB package, i.e. Windows hardlinks already-staged files rather than unpacking — so a "fresh install" reuses whatever is already on disk.

Same root symptom as #46818 (locked, stale): backend healthy, frontend never sends the configure IPC. That report was Windows 11 Home 25H2 (26200.8117) on 1.1617.0.0; this is Windows 11 Pro 26200.8655 on 1.34493.1.0 — four months later, different edition, different build. So the bug is not specific to Home or to that version. Filing separately since #46818 is locked to collaborators.

What Should Happen?

The app should launch, connect to CoworkVMService over the named pipe, and display its main window.

Error Messages/Logs

C:\ProgramData\Claude\Logs\cowork-service.log — service up, app never connects:

00:55:07.634297 Claude VM Service starting...
00:55:07.634297 Waiting for configuration from app via 'configure' method...
00:55:07.635797 [HCS] vmcompute.dll loaded successfully
00:55:07.636297 [HCS] computecore.dll loaded successfully
00:55:07.636297 [HCS] Procs initialized, HCS ready
00:55:07.638299 [HCN] EnumerateNetworks result: []
00:55:07.681375 [Server] Signature verification initialized
00:55:07.681375 [Server]   Subject: Anthropic, PBC
00:55:07.681375 [Server]   Enforce: true
00:55:07.681875 [Server] Named pipe server listening
00:55:07.681875 Service ready. Listening on \\.\pipe\cowork-vm-service
00:55:07.682376 Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
00:55:14.607311 Service stop requested
00:55:14.612363 Service stopped.

No 'configure' call is ever received. The ~7s gap between "Service ready" and "Service stop requested" is identical on every launch.
Also note: [HCN] EnumerateNetworks returns empty, and the recovery-actions warning appears on every start and stop despite the service running as SYSTEM.

Microsoft-Windows-AppModel-Runtime/Admin — no errors, clean teardown:

00:55:07  39  AppContainer Claude_pzs8sxrjxfjjc created successfully
00:55:07 210  Desktop AppX container {B21D973D-...} created
00:55:07 211  process 30300 added to container
00:55:08 201  process 32612 created for Claude_pzs8sxrjxfjjc!Claude [LaunchProcess]
00:55:08 210/211  second container created, process added
00:55:11 217  container {B21D9747-...} removed
00:55:14 217  container {B21D973D-...} removed
00:55:14  68  runtime state -> 0x2

No event 215, no 208, no 0x80070020 — this is NOT the orphaned-Silo path from #53247.
Application Error and Windows Error Reporting contain ZERO Claude entries: Windows does not see a crash, the process exits on its own.

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\ is never created, even with --enable-logging --v=1.
Local Storage, Session Storage and Partitions ARE written, so Electron initializes its storage layer but produces no main.log.

Steps to Reproduce

1. Launch Claude Desktop from the Start menu
2. Process starts, AppX container is created, CoworkVMService starts and listens
3. ~7 seconds later the app exits; Windows shows the "select Repair" dialog
4. No main.log, no Application Error event, no minidump is produced

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.30096.5.0 (before the 18.08.2026 update to 1.32352.1.0)

Claude Code Version

N/A — this is a Claude Desktop issue, not Claude Code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Claude Desktop 1.34493.1.0 (MSIX Claude_1.34493.1.0_x64__pzs8sxrjxfjjc)
Windows 11 Pro 10.0.26200 (build 26200.8655), locale ru-RU
Update chain: 11.08 (1.26832.0.0) → 14.08 (1.28929.0.0) → 18.08 (1.32352.1.0) → current

Net: MSIX registration valid, VM service starts and listens correctly, main process still exits ~7s later without opening the pipe and without writing a single log line. The app produces no diagnostic artifact of any kind — no main.log, no WER entry, no minidump — which makes this class of failure impossible to diagnose from the user side.

Happy to attach full ClaudeSetup.log, cowork-service.log and event-log exports.

ClaudeSetup.log

cowork-service.log

appmodel-runtime.txt
appx-deployment.txt