[BUG] Claude Desktop 2.110.0 (Windows/MSIX): after a quit, every launch fails with renderer "launch-failed, exitCode: 21" until CoworkVMService is restarted

### Preflight Checklist

- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code

### What's Wrong?

After I quit Claude Desktop, the next launch fails. Sometimes a window flashes and closes, sometimes nothing appears at all. Every launch after that fails the same way.

On 2026-09-17, 14 of 18 launches failed, in two episodes. Each episode started right after a normal quit. The first one ended when I rebooted Windows. The second ended when I restarted the bundled Windows service `CoworkVMService` from an elevated PowerShell. The next launch came up normally, with no reboot and nothing else changed.

`main.log` shows the main webview's render process failing to launch within a second of `Starting app`. That is before the app reads any plugin, MCP server or account data.

This is close to #53247 and #84992, where `CoworkVMService` outlives the app and blocks the next launch, but the signature differs. `Microsoft-Windows-AppModel-Runtime/Admin` shows a normal sequence on every failed launch: Desktop AppX container created (210), process added (211, 201), container destroyed (217). There is no event 215 or 208 and no `0x80070020`. `Get-AppxPackage` reports the package status as `Ok`, and there is no "This app can't open" dialog.

### What Should Happen?

The app starts again after it has been quit, without a service restart or a reboot.

### Error Messages/Logs

From `%LOCALAPPDATA%\Claude\Logs\main.log`, a failing launch:

```
2026-09-17 08:19:53 [info] Starting app { appVersion: '2.110.0', isPackaged: true, platform: 'win32', arch: 'x64', nodeVersion: '24.20.0' }
2026-09-17 08:19:54 [info] Main webview render process gone: { reason: 'launch-failed', exitCode: 21 }
2026-09-17 08:19:54 [error] Sentry caught: { type: 'Unknown', value: 'No message', stack: undefined }
2026-09-17 08:19:54 [info] Main webview render process gone: { reason: 'launch-failed', exitCode: 21 }
2026-09-17 08:19:54 [warn] claudeURLHandler: initial mainView load loadURL rejected { code: 'ERR_FAILED' }
```

Ten of the 14 failed launches log the `launch-failed` line. The other four (07:42:34, 08:10:18, 08:10:32 and 08:10:56) stop logging within the first second, and their last entries are the `bootPreconnect` lines.

A healthy launch logs `Loaded https://claude.ai` and `[startup-perf] sidebar painted` four to seven seconds in.

Launch history that day, local time:

| Time | Event |
|---|---|
| 07:14 | launch ok |
| 07:24 | relaunch after a quit, ok |
| 07:38:25 | quit (`cowork_vm_node.log`: "App quit, stopping VM ... Completed in 712ms") |
| 07:38 to 07:47 | ten failed launches |
| 07:49 | Windows reboot |
| 07:51 | launch ok |
| 08:10:14 | quit (`quit-cleanup`: completed, 34 handlers, not timed out) |
| 08:10 to 08:19 | four failed launches |
| 08:22:24 | `Restart-Service CoworkVMService` |
| 08:22:47 | launch ok |

What I ruled out:

- The Windows Application log has no Application Error or WER event for `Claude.exe`. The Code Integrity and AppLocker logs are empty for the period.
- A `chrome-native-host.exe` left running from the profile folder caused an `EBUSY` when the app copied the native host binary at each boot. After I killed it the `EBUSY` was gone and the launch still failed with the same renderer line.
- No `Claude.exe` from the package was left running between launches. The only survivor of the quit was `cowork-svc.exe` (`CoworkVMService`, StartMode Auto).
- Plugin and marketplace files were the same across failing and working launches.

I have a 35 MB Crashpad minidump from the failed launch at 07:42 and can share it privately.

### Steps to Reproduce

1. Run Claude Desktop 2.110.0 (MSIX) on Windows 11 for a while.
2. Quit the app.
3. Start it again.

It is intermittent. Relaunch worked on 2026-09-16 08:51 and on 2026-09-17 07:24 with the same version, and then failed after both later quits.

Workaround, from an elevated PowerShell:

```powershell
Get-Process Claude -ErrorAction SilentlyContinue | Where-Object { $_.Path -like '*WindowsApps*' } | Stop-Process -Force; Restart-Service CoworkVMService
```

### Claude Model

Not sure / Multiple models

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

1.52386.6. Version 2.110.0 was installed on 2026-09-15 21:42. My logs go back to 2026-07-06 and cover thirteen app versions. The string `launch-failed` appears in none of them before 2026-09-17.

### Claude Code Version

Bundled with Desktop: 2.1.271

### Platform

Anthropic API

### Operating System

Windows

### Additional Information

Claude Desktop 2.110.0.0, MSIX from the Microsoft Store (`Claude_2.110.0.0_x64__pzs8sxrjxfjjc`). Windows 11 Enterprise 10.0.26200.9448, a corporate workstation with Microsoft Defender for Endpoint.

I have one successful test of the service restart, so I can say it fixes the state, not why the service blocks the renderer.

Start by reviewing the failing and healthy-launch entries in %LOCALAPPDATA%\Claude\Logs\main.log alongside cowork_vm_node.log, then reproduce a quit and relaunch on Windows 11. Inspect the CoworkVMService lifecycle around the renderer launch and use the elevated PowerShell restart as a comparison; done means the app relaunches successfully after a normal quit without restarting the service or rebooting.

Written by the indexing model from the issue text.