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

Status Open

Reported on v2.1.271

Maintainer reply None cached

Activity 6 comments · opened Sep 17, 2026

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

Run Claude Desktop 2.110.0 (MSIX) on Windows 11 for a while.
Quit the app.
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:

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.

View original on GitHub ↗

4 Comments

jtrobles-cdd · 27 days ago

Same signature on 2.110.1 (MSIX), Windows 11 Pro 26100.

17 cold starts today, 3 succeeded. Launches into an already-running instance (second-instance: suppressing duplicate argv) have never failed — 0 out of 7. launch-failed appears nowhere in my log before today, across 195 app starts going back to 2026-08-21 and ~14 versions.

Two things this rules out, beyond the list in this issue:

A clean reinstall does not fix it. The MSIX was removed and re-added (Deployment Add ... finished successfully, new package created 14:43:57). Cold starts at 14:48:16, 14:48:34 and 14:50:42 failed identically on the fresh install.
Re-registering does not fix it. Add-AppxPackage -DisableDevelopmentMode -Register AppxManifest.xml completed successfully at 17:27:34; cold starts at 17:27:39, 17:27:46, 17:27:52 and 17:28:08 failed with the same line. 17:28:18 then succeeded with nothing changed in between.

Also ruled out here: no Crashpad dump and no WER report (the renderer never starts); 252 GB free; Defender only, and its sole Exploit Guard blocks are the unrelated LSASS rule, present on days with no failures.

Sentry event IDs: e3f885aa462f4ed085e1cd77b7036aba (13:15:24), a1b7c4c594f84aac879ebe2ffee593f3 (14:50:42), 4b2c8bd998b4408aa1d8bce5c9dab684 (17:28:09).

Have not yet tried the CoworkVMService restart; will report back.

susanta-gs1 · 27 days ago

Not just "the app won't relaunch," but that the regression eliminates the only recovery path for a failed local connector, which makes it materially worse than an inconvenience for anyone running local MCP servers.

chineaalvarez · 23 days ago

Additional investigation: Windows sandbox token downgrade / KB5124008 correlation

We investigated this issue in depth on an enterprise-managed Windows device because Claude Desktop consistently worked after a user-session/shell reset, but crashed again after Claude was quit and relaunched.

Environment

Claude Desktop MSIX: 1.37937.3.0
Windows 11 enterprise-managed device
Microsoft Defender for Endpoint present
Claude launched through the normal Windows AppModel/MSIX activation path
Failure occurs during Chromium GPU/renderer sandbox process creation

---

Reproduction

The behavior was consistently reproducible:

Restart explorer.exe or sign out/in.
Claude launches successfully.
Quit Claude completely.
Launch Claude again.
Claude crashes during startup.
Restarting Explorer or signing out/in allows Claude to launch successfully once more.
After Claude is closed again, the issue reproduces.

The failing launch reports:

GPU process launch failed: error_code=21

Claude logs also show:

Main webview render process gone:
reason: 'launch-failed'
exitCode: 21

Eventually Chromium terminates with:

GPU process isn't usable. Goodbye.

---

Troubleshooting performed

During the investigation we ruled out or significantly reduced the likelihood of:

Claude package corruption
MCP servers
DuckDuckGo MCP
CoworkVMService
working directory differences
package identity/AppModel identity differences
duplicate Claude processes
RuntimeBroker
WebView2
SearchHost / StartMenuExperienceHost / TextInputHost / UserOOBEBroker
ShellExperienceHost
AppLocker blocking
Code Integrity blocking
ordinary GPU driver failure
Explorer being the direct launch failure mechanism
malformed Chromium sandbox token ancestry

Direct launching of Claude.exe could work while normal AppModel activation reproduced the failure.

The following diagnostic flags also bypassed the issue:

--disable-gpu-sandbox
--no-sandbox

This pointed strongly toward Chromium's Windows sandbox process-creation path rather than a GPU hardware issue.

---

WinDbg findings

We traced Chromium's sandbox initialization using WinDbg.

Chromium creates a restricted Low Integrity impersonation token:

TokenType: Impersonation
Impersonation Level: Impersonation
Integrity Level: S-1-16-4096
Is restricted token: yes

Chromium then calls:

SetThreadToken(targetThread, sandboxToken)

The call succeeds:

EAX = 1
LastErrorValue = 0
STATUS_SUCCESS

However, Chromium immediately reopens the token from the target thread using:

OpenThreadToken(...)

On a failing launch, the token has silently changed to:

TokenType: Impersonation
Impersonation Level: Identification

So the actual sequence is:

Requested sandbox token
    SecurityImpersonation
            |
            v
SetThreadToken()
    SUCCESS
            |
            v
OpenThreadToken()
    SUCCESS
            |
            v
Actual token on child thread
    SecurityIdentification
            |
            v
Chromium rejects the token
            |
            v
SBOX_ERROR_SET_THREAD_TOKEN (21)
            |
            v
GPU / renderer launch failure

This appears to be the direct mechanism behind the Claude crash.

---

GOOD vs BAD launch comparison

We captured both a working and failing launch.

First launch after session reset

Input sandbox token:
    Impersonation Level = Impersonation

Effective thread token:
    Impersonation Level = Impersonation

Result:
    Claude launches successfully

Subsequent launch in the same Windows logon

Input sandbox token:
    Impersonation Level = Impersonation

SetThreadToken():
    SUCCESS

OpenThreadToken():
    SUCCESS

Effective thread token:
    Impersonation Level = Identification

Result:
    Chromium sandbox error 21
    Claude crashes

This was particularly useful because the GOOD and BAD launches were reproduced in the same Windows logon session.

---

Token ancestry checked with LiveKD

We also inspected the kernel token objects using LiveKD.

Claude broker primary token

Token ID:        5e29458
ParentToken ID:  0
Authentication ID: 54b4cb6

Chromium initial impersonation token

Token ID:        5e92514
ParentToken ID:  5e29458
Authentication ID: 54b4cb6
TokenType: Impersonation
Impersonation Level: Impersonation

Sandbox child primary token

Token ID:        5e92a4d
ParentToken ID:  5e29458
Authentication ID: 54b4cb6
TokenType: Primary

Both Chromium sandbox tokens are therefore correctly derived from the Claude broker token.

This ruled out a broken token parent/ancestry relationship as the obvious cause.

---

Defender-related token difference

While comparing GOOD and BAD launches we found a repeatable difference in the token metadata.

On a working launch, the token path contained a Defender-created claim:

WIN://SYSAGENTID
src=defender
trust=verified

On a failing launch we observed:

Broker primary token:
    pClaimAttributes = NULL

Initial Chromium impersonation token:
    pClaimAttributes = NULL

Sandbox child primary token:
    pClaimAttributes != NULL
    WIN://SYSAGENTID present
    src=defender
    trust=verified

WinDefend://MpDlpProcessIdentifier was also present in the token metadata.

We are not concluding that Microsoft Defender/MDE itself is the root cause.

However, this Defender-related token difference was the final clue that led us to check recent Windows/security update changes.

---

Windows update correlation

At the end of the troubleshooting we correlated the behavior with two recent Windows updates.

September 8, 2026 — KB5124008

The Claude crashing issue appears to have been introduced with:

KB5124008

With KB5124008 installed:

Claude can launch successfully after a session/shell reset.
After Claude is quit, the next launch can reproduce Chromium sandbox error_code=21.
WinDbg shows the sandbox impersonation token being downgraded from SecurityImpersonation to SecurityIdentification.
Restarting Explorer or signing out/in allows Claude to launch once again.
After Claude is quit, the problem reproduces.

Most importantly:

Uninstalling KB5124008 completely stopped the Claude relaunch crash on the affected device.

KB5124008 also introduced a separate Claude/Cowork VM issue in our environment that was corrected on KB5129195

---

September 14, 2026 — KB5129195

The later update:

KB5129195

resolved the separate Claude VM issue.

However, the Claude Desktop crashing issue remained.

Because the Windows updates are cumulative, KB5129195 carries forward the changes introduced by KB5124008, so the sandbox/relaunch crash either remained present or was effectively reintroduced with the newer cumulative update.

Observed behavior:

KB5124008 installed
    -> VM issue present
    -> Claude relaunch crash present

KB5124008 removed
    -> Claude relaunch crash disappears

KB5129195 installed
    -> VM issue resolved
    -> Claude relaunch crash remains/reappears

---

Current conclusion

The evidence points to a Windows regression introduced with the September 2026 update baseline.

The immediate failure mechanism is:

Chromium creates a valid restricted token
    SecurityImpersonation
            |
            v
SetThreadToken()
    SUCCESS
            |
            v
Windows exposes the resulting thread token as
    SecurityIdentification
            |
            v
Chromium detects the unexpected downgrade
            |
            v
SBOX_ERROR_SET_THREAD_TOKEN (21)
            |
            v
GPU / renderer process launch fails
            |
            v
Claude exits

The strongest update-level evidence is:

Uninstalling KB5124008 resolves the issue on the affected device.

There is also a reproducible difference in Defender-related token claims between the working and failing token paths, but it is not yet clear whether this is causal or a side effect of the Windows security-token regression.

tjsmith-veeam · 23 days ago

Based on using Claude Code to investigate itself, appears that Microsoft update KB5124008 is core to the issue occurring.

Claude's terse explanation:
------------------------------------------
Very similar experiences on my end (Windows 11 Enterprise, Claude Desktop MSIX 2.2553.1, package Claude_pzs8sxrjxfjjc):

KB5124008 is installed on this machine; KB5129195 is not. All my exitCode 21 crash-loops trace back to the day KB5124008 was installed.
Restarting CoworkVMService alone did not fix a crash-loop for me — restarting explorer.exe did, matching [this comment's](https://github.com/anthropics/claude-code/issues/95050#issuecomment-5757272470) repro steps exactly.

+1 that this is the Windows sandbox-token regression from KB5124008, not a Cowork/VM-service issue.

Showing cached comments. Read the full discussion on GitHub ↗