[BUG]Claude Desktop repeatedly crashes and requires “Advanced Options → Repair” on Windows
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 repeatedly crashes/stops and Windows then shows:
"You’ll need to go to advanced options for Claude and select Repair. If you’re still having issues with it, reinstall this app or contact your administrator."
Reinstalling Claude does not permanently resolve the issue.
I investigated the CoworkVMService logs. The service initializes successfully:
- vmcompute.dll loaded successfully
- computecore.dll loaded successfully
- HCS initialized successfully
- HCN initialized successfully
- Named pipe server starts successfully
- Claude.exe connects successfully
- Claude's signature is verified
- A VM session is created successfully
The relevant sequence is:
CoworkVMService starts
→ HCS/HCN initialize
→ Claude connects
→ VM session is created
→ Persistent RPC starts
→ RPC connection ends with:
"Persistent RPC: connection ended: failed to read length: EOF"
→ session has no active connections
→ CoworkVMService eventually stops
This happens repeatedly.
There is also a recurring startup warning:
"Warning: failed to open service for recovery config: Access is denied."
I do not know whether this warning is the cause.
There is a second diagnostic issue: Claude's main.log and cowork_vm_node.log silently stop writing at approximately 10 MiB without rotation.
main.log:
10,486,118 bytes
last written: 2026-06-24 23:20:37
cowork_vm_node.log:
10,485,949 bytes
last written: 2026-07-19 06:28:06
10 MiB = 10,485,760 bytes.
No .old/.1 rotated files exist, and there is no final message indicating that logging stopped. Other Claude logs continued writing on 2026-08-09.
I am not claiming the 10 MiB logging issue causes the crash. It prevents useful main-process crash information from being available when the current crash occurs.
The exact root cause of the Claude crash is currently unknown. I am reporting the Cowork RPC EOF, repeated service stops, Windows Repair state, and silent log-size limit because they appear to be related to diagnosing the failure.
What Should Happen?
Claude Desktop should remain running normally without entering a Windows Repair state.
The Cowork VM service should maintain its connection with Claude while required.
If Claude or the Cowork VM encounters a failure, the application should provide a clear diagnostic error rather than simply disconnecting and leaving Windows requiring "Advanced options → Repair".
Logs should also continue writing or rotate when reaching their maximum size rather than silently stopping.
Error Messages/Logs
Persistent RPC: connection ended: failed to read length: EOF
Warning: failed to open service for recovery config: Access is denied.
VM already stopped, nothing to releaseSteps to Reproduce
- Install Claude Desktop on Windows.
- Launch Claude Desktop.
- Use Claude normally.
- After some time, Claude stops/crashes.
- Windows displays the message asking to use Advanced options → Repair.
- Reinstall Claude.
- Launch Claude again.
- The issue eventually returns.
- Check C:\ProgramData\Claude\Logs\cowork-service.log.
- Observe that CoworkVMService initializes successfully and Claude connects.
- Observe that the persistent RPC connection later ends with:
"failed to read length: EOF"
- The CoworkVMService subsequently stops.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
1.26832.0.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Environment:
Claude Desktop: 1.26832.0.0
Package: Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
Installation type: MSIX
Operating System:
Windows 11 Home
64-bit
Build 10.0.26200
System language: zh-CN
CPU:
AMD Ryzen 7 5700G with Radeon Graphics
3.80 GHz
RAM:
24 GB installed
23.4 GB usable
2933 MT/s
GPU:
AMD Radeon(TM) Graphics
Integrated Radeon graphics
496 MB displayed graphics memory
Motherboard:
B550M K
Storage:
477 GB total
460 GB used
Approximately 17 GB free
Claude user data:
C:\Users\User\AppData\Roaming\Claude
Claude logs:
C:\Users\User\AppData\Roaming\Claude\logs\
Cowork service log:
C:\ProgramData\Claude\Logs\cowork-service.log
The Claude MSIX package is installed on a non-system volume.
41 Comments
getting the same issue, it only started happening today
Claude repeatedly crashes immediately after using the Claude Browser MCP.
I reviewed the MCP browser logs rather than relying on the visible UI error.
Today, multiple independent Claude Code sessions in the same project ended immediately after a Claude Browser MCP operation. Seven sessions ended with:
"Tool 'preview_start' completed successfully"
Nothing was logged after that event before the process/session terminated. An additional session ended on a javascript_tool browser operation.
Two failures in the same conversation reproduced the same pattern with:
preview_start
→ app.omivoai.com/login
→ tool reports successful completion
→ no further MCP log entry
→ Claude process/session terminates
This is important because the browser tool itself reports success. There is no browser-tool error explaining the subsequent process termination.
The CoworkVMService logs independently show the corresponding RPC connection eventually ending with:
"Persistent RPC: connection ended: failed to read length: EOF"
The Cowork service initializes successfully, Claude connects successfully, and the VM session is created before the RPC EOF occurs.
Therefore the current evidence suggests that the Cowork EOF may be a consequence of the Claude host process/browser subsystem terminating rather than the Cowork service being the original cause.
The failures occur across unrelated tasks, so this does not appear specific to one repository or command.
Memory pressure also does not appear to be the cause: the machine had approximately 12.2 GB of free RAM out of 23.4 GB usable, with approximately 31% commit at the time of investigation.
The exact native component responsible is not yet known. The likely area to investigate is the Claude Browser MCP / browser pane host and its interaction with the Windows Claude host process, Chromium, or a native/GPU component.
Environment:
it is claude brower mcp
yess, same here
+1, same issue on my machine. Same crash text exactly. Repair also fails for me after 3 attempts, not just once.
Additional finding: Remove-AppxPackage with -PreserveApplicationData fails with HRESULT 0x80073CFA (flag unsupported on this package type — had to remove without it, which worked).
Also seeing a second effect: after removing/reinstalling, Code tab session history disappears from the sidebar (matches #62997), even though the actual session files are still intact on disk at ~/.claude/projects/.
Claude Code version: 2.1.227
Same thing happened for me, crashes whenever the Claude browser MCP is used. The cause was an orphaned chrome-native-host.exe process left over from a previous session, holding a lock on its own executable. On init the app tries to refresh that binary from the package into %APPDATA%\Claude\ChromeNativeHost\, gets EBUSY: resource busy or locked, and dies. Windows "Repair" appears to fix it only because tearing down the package container kills the orphan.
Fix for me was: taskkill /F /IM chrome-native-host.exe
Same failure here, on a newer build, and I think I have the mechanism. It is the MSIX update path, and the thing blocking it is Claude's own Windows service.
Environment: Windows 11 Pro 10.0.26200, Claude
1.28929.0.0, MSIX on the system volume (so the "non-system volume" detail in the report is not required to reproduce).The service runs from inside the versioned package directory
The service binary path carries the version number, so every update has to replace the directory that an always-running LocalSystem service is executing out of. A running service pins that directory, and
ForceTargetApplicationShutdownOptionshuts down app processes, not services. So the register step fails with0x80073D02(ERROR_INSTALL_RESOURCES_IN_USE), Windows falls back to offering Repair, and Repair hits the same wall.Timeline from Microsoft-Windows-AppXDeploymentServer/Operational
Note the last pair: after a full Repair, the register is blocked by the same version it just installed, because the service came back up from the new path before registration completed. That is the loop.
Same window, same log:
Two corrections to the original diagnosis
The
Persistent RPC: connection ended: failed to read length: EOFline is not the failure. InC:\ProgramData\Claude\Logs\cowork-service.logit appears on 2026-07-23, 07-24, 08-03, 08-07 and twice on 08-12, every time immediately before or during a normal app exit, including exits followed by perfectly clean starts. Where it is followed byHcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032(ERROR_NOT_SUPPORTED) that is just the graceful VM shutdown falling back to a forced terminate. Both are consequences of the app going away, not causes of the Repair state.The 10 MiB silent truncation does not reproduce.
main.logrotates here, it does not stop at 10,485,760 bytes:Worth adding for anyone landing here from a search: this is not a crash and not a bluescreen. On this machine there is no bugcheck record in the System log, no Kernel-Power 41, and
C:\Windows\Minidump,MEMORY.DMPandLiveKernelReportsare all empty. If you see a burst of WERBlueScreen/LiveKernelEvententries in the Application log right after boot, check the creation dates onC:\ProgramData\Microsoft\Windows\WER\ReportQueuebefore blaming them. Mine span 2025-12-04 to 2026-08-04 and were simply flushed to the upload queue at boot.Crashpad\reportsis also empty, andmcp.logis 0 bytes, so the browser/MCP theory circulating on this issue has nothing behind it either.What clears it
Stop the service before repairing, elevated:
After that,
Get-AppxPackage Claudereports1.28929.0.0/Status: Ok.Suggested fix
Any one of these breaks the cycle:
cowork-svc.exeoutside the versioned package directory, so an update never has to replace a path a running service holds.CoworkVMServicein the update pre-flight and start it after registration, rather than relying onForceTargetApplicationShutdownOption, which does not touch services.DeferRegistrationWhenPackagesAreInUsestaging so the deferred register can complete at next launch.Secondary, and probably unrelated to the Repair loop but visible at every single service start going back to 2026-07-15:
Warning: failed to open service for recovery config: Access is denied.The service is LocalSystem and still cannot set its own SCM recovery configuration, so it has no restart policy when it does die.Same issue here on Windows 11. App worked fine for a few days, then started failing to launch with "Can't open this application — go to advanced options for Claude and select Repair." Repair and Reset both failed with "Repair/Reset failed."
Troubleshooting done, none of it fixed it permanently:
wsreset (Store cache reset) — no effect
Re-registering all AppX packages via PowerShell — Claude package registered without errors
DISM /Online /Cleanup-Image /RestoreHealth — completed successfully
sfc /scannow — found and repaired corrupted system files, issue still recurred
Fully removed the package (Get-AppxPackage Claude | Remove-AppxPackage -AllUsers) and reinstalled from claude.ai/download — worked temporarily, then broke again
Tried disabling the InstallService (AppX background update service): PowerShell gave "Access is denied" even though my account is a local administrator with UAC confirmed; had to disable it manually via services.msc instead. Same "access denied" behavior when trying to pause Store auto-updates from Store settings, despite admin rights.
Fully uninstalled the Microsoft Store app itself — no errors, issue still recurred after reboot
Did a full in-place Windows 11 reset via setup.exe from a fresh ISO (keep files and apps) — issue persisted after that too
No third-party antivirus/cleaner installed, Windows Defender was disabled, and the issue reproduced with the system VPN fully disabled as well.
The recurring "access is denied" on service management despite full admin rights lines up with the failed to open service for recovery config: Access is denied error mentioned in this thread — seems like the same root cause.
I'm hitting the same crash pattern described in this issue (main process hangs after RPC/VM connection drop, requires Settings → Apps → Claude → Repair to relaunch).
In my case, the crash started right after a Cowork session that ran a long sequence of browser automation actions (opening a deployed site, navigating a form, verifying env vars/deploys across multiple tool calls) — the app was fine before that session and became unrecoverable (silent close, wouldn't reopen without Repair) partway through it.
This seems consistent with the CoworkVMService / persistent RPC "connection ended: failed to read length: EOF" pattern already reported here — happy to share logs if useful.
OS: Windows 11
Claude Desktop version: Versão 1.28929.0 (d1a6bc)
this claude brower mcp issue , say do not use brower mcp to claude when working project file insted use curl
Same symptom on Windows 11. Additional diagnostic data that may narrow the cause.
Symptom: Windows dialog "Can't open this app - You'll need to go to advanced
options for Claude and select Repair." App never launches. Repair and reinstall
both fail to hold.
Package state:
Name : Claude
Version : 1.28929.0.0
Status : Modified, NeedsRemediation
SignatureKind : Developer
The package folder was created fresh at 2026-08-13 01:01 and already showed
Modified, NeedsRemediationwithin minutes. A clean reinstall corruptsimmediately on deployment.
Ruled out:
chkdsk C: /scan- no problems, no bad sectorssfc /scannow- no integrity violationsAdd-AppxPackage -Registeragainst the on-disk manifest completedsuccessfully but did not clear the status
Possibly related: CoworkVMService dependency gap
sc.exe qc CoworkVMService returns:
TYPE : 210 WIN32_PACKAGED_PROCESS
START_TYPE : 2 AUTO_START
DEPENDENCIES : staterepository
No dependency on
hnsorvmcompute. As an AUTO_START service it races bothat boot, and this appears at every service start in cowork-service.log:
[Cleanup] Warning: failed to enumerate HCN networks: HcnEnumerateNetworks
failed with HRESULT 0x800706d9
0x800706D9 is EPT_S_NOT_REGISTERED, consistent with the HNS RPC endpoint not
being available yet. On this machine
hnswas also found set to Disabled;setting it to Automatic did not resolve the app launch failure.
Also present at every start:
Warning: failed to open service for recovery config: Access is denied.
The service therefore cannot register an auto-restart policy, so once it stops
it stays stopped.
Environment: Windows 11 (10.0.26100.9168), Claude Desktop 1.28929.0.0
installed from anthropic.com, WSL2 with networkingMode=mirrored, Defender only.
I hit this twice and pulled the AppX deployment log. There look to be two distinct file-lock failures involved, and I think the second one is why Repair and reinstall never recover.
Environment
Claude_1.28929.0.0_x64__pzs8sxrjxfjjc)All log lines below are from
Microsoft-Windows-AppXDeploymentServer/Operational.Failure 1: the update cannot retire the running old version (0x80073D02)
The new version was staged while the old one was still running, and the registration that finalizes the swap failed because the old package was in use. The app was unlaunchable after this.
Failure 2: recovery is blocked by chrome-native-host.exe (0x5 → 0x80073CF6)
Every attempt to fix it by repairing, uninstalling, or reinstalling ran into a second lock. During package servicing Windows tries to clear the package data folder and cannot delete this file:
0x5is ACCESS_DENIED, which is what Windows returns when you try to unlink a currently-executing image, so that binary was running. It is the native messaging host for the Claude browser extension, launched by Chrome. Each time, the failed deletes were followed immediately by:That exact sequence happened twice in one day, at 2:13 PM and again at 4:20 PM. Both reinstalls failed. The two reinstalls that did succeed (2:25 PM and 4:28 PM) were the ones where the native host was not running.
Full sequence from the log, all one day
Suggested fix
The package manifest already terminates the packaged service during servicing. These succeed every single time:
Nothing does the equivalent for
chrome-native-host.exe. If the updater terminated the native messaging host the same way it terminatesCoworkVMService, failure 2 would go away and Repair would actually repair.For failure 1, applying an update while the current version is still running is what sets up the broken state to begin with.
Impact
Every occurrence kills my active Remote Control sessions. They do not survive and do not come back once the app works again, so in-flight work is lost. That is the part that actually costs me, more than the downtime.
Workaround for anyone else hitting this
Close Chrome, or kill
chrome-native-host.exe, before repairing or reinstalling. The reinstalls that worked for me were the ones where it was not running.Happy to provide a full AppXDeploymentServer log export if that would help.
Confirming the sidebar-history-loss side effect @1bbqfreak-ui mentioned (and #62997): hit it twice in a row, same as reported: Code tab history vanishes from the sidebar after each forced reinstall, while the actual transcripts in ~/.claude/projects//.jsonl are completely untouched.
Dug into the mechanism since it isn't detailed in #62997: the sidebar doesn't read ~/.claude/projects directly. It reads small stub files at AppData\Roaming\Claude\claude-code-sessions\\<workspace-id>\\<project-id>\\local_<guid>.json, each with a cliSessionId pointing at the real transcript UUID plus cwd/timestamps/title. That registry folder gets wiped on reinstall along with the rest of app data, but the transcripts it points to don't, so it's fully reconstructable by regenerating one stub per transcript. Did that manually both times to get history back.
Also relevant to the Browser-MCP theory upthread: I had three sessions open when the second crash hit. The one whose transcript actually ends with the RPC cutoff was pure filesystem/PowerShell work, but a second, concurrent session was mid-loop on Claude Browser MCP automation (repeated navigate/computer/get_page_text/preview_start calls), and its last logged activity is within about 10 seconds of the other session's cutoff. So this is consistent with the Browser-MCP correlation reported upthread, not counter-evidence against it.
I'm not using Co-Work at all, still crashes on Claude Desktop. Just passed back to using more windows on VS.
I am experiencing the same issue with Claude Desktop 1.30096.1 (194d93), released on 2026-08-13.
When I try to use Cowork, I get the following error:
"Failed to start Claude's workspace"
"RPC pipe closed"
"Restarting Claude or your computer may resolve the issue. If the problem persists, you can reinstall the workspace or share debug logs to help us improve."
I have already reinstalled the workspace about twice, but the same error continues to occur.
As a result, Claude cannot access the sandbox/workspace properly, so shell/terminal operations in Cowork do not work.
I also checked the CoworkVMService separately:
\\.\pipe\cowork-vm-servicenamed pipe is created and listening.Client connected.Persistent RPC: connection ended: failed to read length: EOFmessage in my logs.Is there any known workaround or additional troubleshooting I can try for this issue?
Same issue!!!
same issue
Same issue. Unable to repair. Reinstall loses left sidebar pointers to conversations. Issue re-occurs after some time.
Went through it with Claude. It is at least functional for now. But this needs a real fix on the installer side.
Spent several hours debugging this on Win11 Pro today and got it resolved. Sharing findings because I think a couple of them are general, not specific to my machine, and they explain why the Repair button in the OP can never succeed.
TL;DR: the underlying state is
Status : Modified, NeedsRemediationon the MSIX package. Windows' Repair cannot clear it because the installer stages from a temp.msixthat is deleted immediately after install, so the recorded package source no longer exists. TheEOF/VM already stoppedlines incowork-service.logare normal shutdown noise, not the fault.---
1. Why "Repair" always fails (reproducible for everyone)
Microsoft-Windows-AppXDeploymentServer/Operationalon every Repair attempt:0x80073CF0= ERROR_INSTALL_OPEN_PACKAGE_FAILED,0x80070002= file not found.The Windows installer is an
.exewrapper that extracts an.msixto%TEMP%under a generated name (Claude-<random>.msix), callsAdd-AppxPackageon it, and the temp file does not survive. Windows records that path as the package's install source. From that moment on, any remediation Windows attempts has nothing to read.I confirmed the naming pattern by polling
%TEMP%during a reinstall and catchingClaude-2900286510.msix(255 MB).Net effect: Settings → Advanced options → Repair is a dead end for this app by construction. It is not a permissions problem, a Hyper-V problem, or user error. Worth fixing installer-side, either by leaving the msix on disk or by registering a durable source path.
2.
Start-Serviceon the Cowork service always returns error 87 (dead end, don't chase it)Type
210is an MSIX packaged service. These cannot be started manually viaStart-Serviceor services.msc, because SCM has to launch them inside a package identity context that only app activation sets up.error 87: The parameter is incorrectis the expected response, not a symptom. I burned a lot of time here.Also benign, seen on every service start:
3. The log lines the OP flagged are normal shutdown
Immediately before these, my log shows a completely healthy VM lifecycle:
The
EOFis just the app disconnecting on close. The Cowork VM stack was never the problem.vfpext,vmcompute,hns, andHvHostwere all running andVirtualMachinePlatformwas already fully enabled.4. Log locations (the OP's paths are wrong for MSIX)
%APPDATA%\Claude\logs\does not exist. MSIX filesystem redirection puts it here:I did not reproduce the 10 MiB log stall from the OP. Mine were 1.1 MB and actively writing, so that may be a separate issue.
5. Diagnosis
One command tells you if this is your problem:
Status : Modified, NeedsRemediationmeans Windows considers the package files altered from their signed state. This is what triggers the "close / advanced options" modal.Supporting detail:
Note that re-registering (
Add-AppxPackage -RegisterByFamilyName) succeeds with0x0and does not clear the flag — it only rebuilds registration metadata, it does not re-stage files. That's why the loop repeats indefinitely.6. Non-destructive recovery (better than uninstall/reinstall)
Reinstalling works but a full uninstall loses local conversation history. Re-staging in place does not:
This rewrites the package files and clears
Modified, NeedsRemediationwhile leavingLocalCacheuntouched.To get an
.msixto point it at, run this in a second admin window, then start the.exeinstaller, then Ctrl+C:Back up first regardless:
Running the
.exeinstaller over the top also worked for me and cleared the flag, with history intact.7. What I could not determine
Being explicit about the limits of this, since the above fixes the symptom rather than the cause:
Modifiedflag is unknown. Disks all report Healthy, Defender has no relevant detections, disk space was fine at 164 GB free.MicrosoftCorporationII.WindowsSubsystemForLinuxis in the identicalModified, NeedsRemediationstate. That suggests something system-level rather than an app bug, and may be unique to my install.C:\Program Files\WindowsApps\Claude_1.24012.0.0_x64__pzs8sxrjxfjjcis still on disk with no entry in the package database. Points to an interrupted update at some earlier date, possibly the origin.So sections 1 through 6 should apply to anyone. Section 7 may be mine alone.
---
Environment: Windows 11 Pro, Claude 1.30096.1.0 (MSIX,
Claude_pzs8sxrjxfjjc), Hyper-V/VMP enabled, 164 GB free on C:.Suggested fixes for the app side:
.msix(or register a durable source path) so Windows Repair can actually function.NeedsRemediationat launch and offer in-place re-staging, instead of handing users off to a Repair button that cannot succeed.main.log/cowork_vm_node.lograther than silently stopping at 10 MiB (per the OP).install without uninstalling claude code and it will work without loosing anything and menttion donot use claude browers mcp tool in prompt or directly say , it will use other method and it will work fine
Adding a data point that pins the browser-pane variant of this to a specific mechanism: the Electron GPU process crashes ~7–20 s after the Claude Browser pane opens, and that takes the app down. The Cowork
Persistent RPC: connection ended: failed to read length: EOFline follows as a consequence, consistent with @SprucetheAI's correction — but on this machine the browser/MCP trigger is real and 5-for-5 reproducible.Evidence (
%APPDATA%\Claude\logs\main.log)Every
[Preview] Created browser previewtoday was followed within 7–19 seconds by a GPU process crash with the same exit code, and then app termination:101457950=0x60C201E. ZeroGPU process goneevents in the four previous rotated main logs (back to 2026-06-08). Correspondingcowork-service.logentry for the last one:The
capturePreviewScreenshot failedwarning coinciding with one of the crashes suggests the preview screenshot/compositing path as the specific GPU operation that dies, but that is one sample.The rest of the app (Code sessions, MCP servers, WebFetch/WebSearch, Claude-in-Chrome via real Chrome) is stable — only the in-app browser pane triggers it. No orphaned
chrome-native-host.exepresent, no EBUSY in the log, so this is a different mechanism from the one @Methode7H hit.Environment
Claude_1.30096.5.0_x64__pzs8sxrjxfjjc), Claude Code 2.1.229 — first run of this build was this morning; the two browser-pane opens on earlier builds in July did not crashWorkaround
Don't open the Claude Browser pane; use WebFetch/WebSearch or Claude-in-Chrome instead. Happy to collect a GPU crash dump or run a build with
--disable-gpu/ hardware acceleration off if that helps triage.is there a fix yet ?
I've been hit with the same issue now today as well. No joy since early this morning.
same issue
<img width="362" height="132" alt="Image" src="https://github.com/user-attachments/assets/db62b65d-24e3-4605-99c7-a6bbd786a995" />
Claude Desktop for Windows: Cowork
RPC pipe closedWorkaround1. Confirm the problem
If Cowork fails with:
open:
Look for repeated messages such as:
If this message appears repeatedly, the following workaround may apply.
2. Workaround
Close Claude Desktop completely.
Open PowerShell as Administrator.
Copy the signed
cowork-svc.exefrom the installed Claude package:When
xcopyasks:Press
FVerify the signature:
It should show:
Stop the packaged Cowork service:
Then, before starting Claude Desktop, run the copied
cowork-svc.exemanually:A successful startup should include:
Leave this PowerShell window running. Do not close it.
Only after
cowork-svc.exeis running, start Claude Desktop normally.3. Verify that Cowork actually works
Haiku is recommended because this is only a connectivity/sandbox test, so it minimizes unnecessary usage.
<filename>with that filename and send:The test is successful only if Claude starts the isolated Linux sandbox and uses the sandbox shell to read the specified text file.
If the previous:
error does not occur and the file is successfully read through the Cowork sandbox, the workaround is confirmed to be working.
4. After Claude Desktop is updated
This is a workaround, not a permanent product fix.
After a Claude Desktop update, the copied
cowork-svc.exemay belong to the previous version. Remove the old workaround file before creating a new one:Then repeat the copy step using the
cowork-svc.exefrom the newly installed Claude version.Reference: Anthropic issue #35281 documents the same class of Windows Cowork signature-verification problem and the interactive
cowork-svc.exeworkaround.Same issue happened to me (https://github.com/anthropics/claude-code/issues/87171), the workaround is ugly, of course, but it worked (thanks!).
You’ll need to go to advanced options for Claude and select Repair. If you’re still having issues with it, reinstall this app or contact your administrator.
I’m experiencing the same issue. I’m using Browser MCP on a system with an AMD Ryzen 7 5700G, and I have never encountered this issue before.
After repairing Claude, it continues to crash and requires another repair.
You'll have to tell it to stop using the browser mcp and use the chrome mcp (need the chrome extension).
<html><body>
<!--StartFragment--><p dir="ltr">Adding a data point on a much newer build, with what I think is the missing piece: <strong>the crash is an Electron GPU process crash, and <code>CoworkVMService</code> is the victim rather than the cause.</strong></p>
<h2 dir="ltr">Environment</h2>
<div dir="ltr">
|
-- | --
Claude Desktop | 1.32885.1.0 (MSIX, direct download from anthropic.com — not Store)
OS | Windows 11, build 10.0.26200
GPU | NVIDIA RTX 4090, driver 32.0.16.1088 (610.88)
RAM | 64 GB
Install volume | System volume (C:), ~ample free space
AV/EDR | Windows Defender only — no third-party agent
</div>
<h2 dir="ltr">The RPC EOF is a symptom, not the cause</h2>
<p dir="ltr">The original report focuses on <code>Persistent RPC: connection ended: failed to read length: EOF</code>. In my <code>cowork-service.log</code>, the VM is demonstrably still healthy <strong>after</strong> that EOF:</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">15:44:15.147 [Server] Persistent RPC: connection ended: failed to read length: EOF
15:44:15.147 [Server] Session ... has no active connections, idle timeout starts
15:44:20.753 [HCS] Properties result: {... "State":"Running"}
15:44:30.753 [HCS] Properties result: {... "State":"Running"}
15:44:38.497 Service stop requested</code></pre></div></div>
<p dir="ltr">The VM reports <code>Running</code> for 23 seconds past the EOF, then the service shuts down cleanly on request. The service is behaving correctly throughout — the EOF is <code>claude.exe</code> dying and taking its end of the pipe with it.</p>
<p dir="ltr">(Also note <code>HcsShutdownComputeSystem failed with HRESULT 0x80070032</code> on every stop — that's <code>ERROR_NOT_SUPPORTED</code>, i.e. the guest has no ACPI shutdown handler. It always force-terminates. Looks alarming in the log, isn't relevant.)</p>
<h2 dir="ltr">What actually kills the app</h2>
<p dir="ltr">Last line of <code>main.log</code> before every crash:</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">[Preview] Created session preview context { previewId: 'preview-local_...' }
[Launch] Updating active servers store { count: 1, servers: '[{"serverId":"browser-preview-...","status":"running",...}]' }
[Preview] Created browser preview { serverId: 'browser-preview-...' }
...
[warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
[info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}</code></pre></div></div>
<p dir="ltr">Timeline across the ~3 minutes:</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">16:54:41 VM startup complete (11751ms) — clean
16:55:46 Code session starts, first assistant response at 9.2s — fine
16:57:32 Browser Preview created; new renderer spawns
16:57:34 GPU process memory 135MB -> 186MB
16:57:37 GPU process crashed, exitCode 101457950 — app dies</code></pre></div></div>
<p dir="ltr"><strong>Reproducible trigger:</strong> any Code-session action that creates a browser surface. Asking the agent to pull a list off a website does it every time. Sessions that never open a browser view are stable.</p>
<p dir="ltr">Memory is not a factor — <code>sys_free=27877MB/65300MB</code> at the moment of the crash.</p>
<h2 dir="ltr">The driver is not the problem</h2>
<p dir="ltr">This is the part that preempts the usual triage response. <code>chrome://gpu</code> on the same machine, same driver, at the same time:</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">GPU0: [NVIDIA GeForce RTX 4090], DRIVER_VERSION=32.0.16.1088 ACTIVE
GL implementation parts : (gl=egl-angle,angle=d3d11)
Driver D3D12 feature level : D3D 12.2
DirectML feature level : 5.0
Direct composition : true
Supports overlays : true
GPU process crash count : 0
Canvas / Compositing / Rasterization / WebGL / WebGPU : Hardware accelerated</code></pre></div></div>
<p dir="ltr">Chrome is completely healthy. Zero GPU process crashes. Meanwhile Claude's own <code>%APPDATA%\Claude\logs\gpu-info.json</code> reports:</p>
<div role="group" aria-label="json code" tabindex="0"><div><div></div></div><div>json</div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code class="language-json" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre;"><span style="color: rgb(155, 233, 99);">"glImplementationParts"</span>: <span style="color: rgb(155, 233, 99);">"(gl=none,angle=none)"</span>,
<span style="color: rgb(155, 233, 99);">"dx12FeatureLevel"</span>: <span style="color: rgb(155, 233, 99);">"Not supported"</span>,
<span style="color: rgb(155, 233, 99);">"supportsVulkan"</span>: <span style="color: rgb(94, 237, 237);">false</span>,
<span style="color: rgb(155, 233, 99);">"skiaBackendType"</span>: <span style="color: rgb(155, 233, 99);">"None"</span>,
<span style="color: rgb(155, 233, 99);">"directComposition"</span>: <span style="color: rgb(94, 237, 237);">false</span>,
<span style="color: rgb(155, 233, 99);">"inProcessGpu"</span>: <span style="color: rgb(94, 237, 237);">true</span>,
<span style="color: rgb(155, 233, 99);">"sandboxed"</span>: <span style="color: rgb(94, 237, 237);">false</span>,
<span style="color: rgb(155, 233, 99);">"gpuDevice"</span>: <span style="color: rgb(211, 215, 222);">[</span> <span style="color: rgb(211, 215, 222);">{</span> <span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">deviceString</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:</span> <span style="color: rgb(155, 233, 99);">"NVIDIA GeForce RTX 4090"</span><span style="color: rgb(211, 215, 222);">,</span> <span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">active</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:</span> <span style="color: rgb(94, 237, 237);">false</span> <span style="color: rgb(211, 215, 222);">},</span>
<span style="color: rgb(211, 215, 222);">{</span> <span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">deviceString</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:</span> <span style="color: rgb(155, 233, 99);">"Microsoft Basic Render Driver"</span><span style="color: rgb(211, 215, 222);">,</span> <span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(244, 123, 133);">active</span><span style="color: rgb(211, 215, 222);">"</span><span style="color: rgb(211, 215, 222);">:</span> <span style="color: rgb(94, 237, 237);">false</span> <span style="color: rgb(211, 215, 222);">}</span> <span style="color: rgb(211, 215, 222);">]</span></code></pre></div></div>
<p dir="ltr">Neither GPU marked active — not even the Basic Render Driver fallback. ANGLE and D3D12 don't load at all. Same machine, same driver, same Chromium lineage, opposite result.</p>
<p dir="ltr">Possibly relevant, from <code>chrome://gpu</code> → Problems Detected:</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Some drivers are unable to reset the D3D device in the GPU process sandbox
Applied Workarounds: exit_on_context_lost</code></pre></div></div>
<p dir="ltr">Chromium's policy on NVIDIA is to kill the GPU process on device loss rather than attempt recovery. Creating a browser preview surface is exactly the kind of operation that triggers a device reset. Chrome survives it because the GPU process is isolated and restarts; here it appears to take the whole app down (note <code>inProcessGpu: true</code>, <code>sandboxed: false</code> above).</p>
<h2 dir="ltr">No hardware acceleration workaround exists</h2>
<p dir="ltr">The standard mitigation is unreachable under MSIX. Launching the packaged exe directly to pass <code>--disable-gpu</code> / <code>--disable-gpu-compositing</code> loses package identity:</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">[ERROR:net\disk_cache\cache_util_win.cc:25] Unable to move the cache: Access is denied. (0x5)
[ERROR:net\disk_cache\disk_cache.cc:284] Unable to create cache</code></pre></div></div>
<p dir="ltr">Identical to what's reported in #77857 (closed as <code>invalid</code>, scope — not resolved). There is no settings toggle, no <code>.lnk</code> to edit, and <code>ELECTRON_EXTRA_LAUNCH_ARGS</code> is ignored. A toggle has been requested across #26302, #56805, #45031, #25801, #31643, and #77857 spanning 1.1.3189 → 1.32885.1.0.</p>
<h2 dir="ltr">Ruled out</h2>
<p dir="ltr">Everything below was tested and did not change the behavior:</p>
<ul dir="ltr">
<li><strong>Repair</strong> via Advanced options (with all processes and the service confirmed stopped first)</li>
<li><strong>Uninstall / reinstall</strong> — repeatedly</li>
<li><strong>Package re-registration</strong> — <code>Add-AppxPackage -DisableDevelopmentMode -Register</code> returns success, status unchanged (expected: re-register rebuilds registration, not payload)</li>
<li><strong>Orphaned package directory</strong> — <code>Remove-AppxPackage</code> left a stub behind (<code>AppxManifest.xml</code>, <code>app\*.pak</code>, <code>app\locales\</code>); removed via takeown + delete, then clean reinstall. Crash returned.</li>
<li><strong>AV / EDR</strong> — Defender only, zero detections, zero quarantine, no third-party minifilters (<code>fltmc</code> shows Microsoft built-ins only)</li>
<li><strong>ACLs</strong> — verified correct after deployment repair: <code>TrustedInstaller:(F)</code>, <code>SYSTEM:(F)</code>, <code>Administrators:(CI)(RX)</code>, <code>Users:(RX)</code></li>
<li><strong>Component store</strong> — <code>DISM /RestoreHealth</code> + <code>sfc /scannow</code>, then reboot</li>
<li><strong>Stale VM bundle</strong> — moved <code>%APPDATA%\Claude\vm_bundles</code> aside; VM rebuilt and started clean (11.7s). Fixed the VM side; crash unaffected.</li>
<li><strong>GPU driver</strong> — updated to current (610.88). Chrome healthy, Claude unchanged.</li>
<li><strong>Display driver TDR</strong> — zero Event ID 4101 in the System log. Not a driver reset.</li>
<li><strong>Memory pressure</strong> — 27 GB free at crash time</li>
</ul>
<h2 dir="ltr">Package status flag</h2>
<p dir="ltr"><code>Get-AppxPackage Claude</code> reports <code>Modified, NeedsRemediation</code> after each crash, and returns to that state after a clean reinstall once the app is used. It is the only flagged package on the system (<code>Get-AppxPackage | Where Status -ne 'Ok'</code> returns Claude alone).</p>
<p dir="ltr">Given the ACL and payload checks above, I now read this as <strong>downstream of the repeated hard crashes</strong> rather than a cause — the deployment stack concludes the package is damaged after a packaged app dies abnormally enough times. Worth flagging because it sends people (me, for two days) down a package-integrity path that leads nowhere.</p>
<p dir="ltr">Corroborating: <code>AppXDeploymentServer/Operational</code> event 649 during registration —</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc
ACLs repaired successfully. Register next time should succeed.</code></pre></div></div>
<h2 dir="ltr">Two secondary issues</h2>
<p dir="ltr"><strong>1. <code>cowork-service.log</code> has no rotation.</strong> Mine reached <strong>766,717,298 bytes</strong> (~766 MB). This is the inverse of the original report's 10 MiB silent stop — here it grows without bound. It logs the full HCS config JSON on every VM start and polls <code>HcsGetComputeSystemProperties</code> every 10s during idle countdown. The per-user <code>main*.log</code> files rotate correctly; the ProgramData service log does not.</p>
<p dir="ltr"><strong>2. Recovery actions fail on every service start:</strong></p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
Warning: failed to disarm recovery actions for this stop: open service: Access is denied.</code></pre></div></div>
<p dir="ltr">A <code>LocalSystem</code> service should be able to set its own restart policy. Consequence is in the message itself — after a crash the service stays down until reboot.</p>
<h2 dir="ltr">Suggested fixes</h2>
<ol dir="ltr">
<li>Isolate/restart the GPU process instead of letting its death terminate the app (<code>inProcessGpu: true</code> + <code>exit_on_context_lost</code> is a bad combination on NVIDIA).</li>
<li>Investigate why the GPU stack fails to initialize at all — <code>(gl=none,angle=none)</code> on a machine where Chrome reports <code>(gl=egl-angle,angle=d3d11)</code> on the same driver.</li>
<li>Ship the hardware acceleration toggle, or support a flag mechanism that works under MSIX. Six months of requests; there is currently no supported mitigation for any GPU-related failure in this app.</li>
<li>Rotate <code>cowork-service.log</code>.</li></ol><!--EndFragment-->
</body>
</html>
Adding another confirmed data point for the Browser pane GPU crash variant (thanks @Falkicon for pinning the mechanism) — this one on Intel integrated graphics, not NVIDIA/AMD, so the root cause isn't vendor-specific.
Evidence (
%APPDATA%\Claude\logs\main.log)Same shape as @Falkicon's log: crash lands within seconds of the Browser pane/Preview opening, app goes down right after.
Environment
Claude_pzs8sxrjxfjjc)Workaround that worked for me
Same as @Falkicon: stop asking Claude to open the in-app Browser pane. Using
WebFetch/WebSearchinstead avoids the crash entirely; only visual/interactive browsing through the Preview pane triggers it.Given this now reproduces across NVIDIA, AMD, and Intel GPUs, it seems very unlikely to be a driver-specific issue — points more strongly at the Electron GPU process being run in-process/unsandboxed (
inProcessGpu: true, sandboxed: falseper earlier comments) with no working--disable-gpuescape hatch under MSIX. A supported way to disable hardware acceleration (or at minimum, isolating/restarting the GPU process instead of letting its death take the whole app down) would fix this for good.Additional data point: update failure is caused by CoworkVMService holding cowork-svc.exe
Same symptom as reported here — Claude Desktop shuts down on its own and only a
manual reinstall brings it back. AppX deployment logs show this is not a crash:
the app quits cleanly to apply a pending update, and the update then fails.
Environment: Windows, MSIX install, 1.32885.1.0 → 1.34493.1.0
Sequence (repeats every update cycle):
[658] Marking package {Claude_1.34493.1.0_x64} for deferred registrationbecause {Claude_1.32885.1.0_x64} is still running
main.log:[info] beforeQuitForUpdate handler fired, going down for update[info] Windows session ending (close-app) - quitting the appNo exception, no GPU crash, no memory pressure (3.1 GB RSS, 15/32 GB free).
[419] error 0x80073D02: Unable to install because the following apps need tobe closed Claude_1.34493.1.0_x64
[462] error 0x80070020: Creating file\\?\C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64\app\resources\cowork-svc.exe failed.
0x80070020is ERROR_SHARING_VIOLATION.Root cause: CoworkVMService keeps running after Claude exits and holds a
handle on
cowork-svc.exe, so the deferred registration can never complete.The old package is already gone at that point, which is why the app disappears
and a reinstall looks like the only fix.
Workaround (avoids reinstalling and preserves chats/settings/MCP config):
stop the Cowork service, then complete the registration manually:
Expected behaviour: the updater should stop CoworkVMService as part of
beforeQuitForUpdate, and should not remove the existing package until the newone has registered successfully.
Same crash, twice in one day — with Windows-side log evidence
Environment: Windows 11 Pro 10.0.26200 · Claude desktop 1.34493.1.0 (MSIX,
C:\Program Files\WindowsApps) · Ryzen 7 7800X3D, 32 GB RAM, RTX 4080 SuperSymptom is exactly what's described here: the Claude window closes silently, clicking the desktop icon brings up the Windows app-repair screen, repair does nothing, and ultimately only a full system restart brings the app back.
Load correlation: both crashes (2026-08-23, ~17:42 and ~17:53 local) happened while one Claude Code session was running 4 parallel background research subagents and a second session was simultaneously coding and committing. I have never seen this crash outside that kind of parallel-agent load. Note these were local sessions — the Cowork VM was not in use;
cowork-service.logshows[VM] VM already stopped, nothing to releaseat crash time. So on my machine the trigger doesn't look like Cowork-VM agents specifically, but general multi-session/subagent load.What Windows recorded (Event Viewer +
AppXDeploymentServer/Operationallog):claude.exeat all — the process exits rather than faults, so nothing OS-side captures the cause.RegisterByPackageFullName ... RepairAppRegistrationOption, withTrying to repair ACLs for ...WindowsApps\Claude_1.34493.1.0...→ACLs repaired successfully. These ACL repairs appear on virtually every launch, including successful ones — the package permissions seem chronically broken, which would explain why reinstalls don't stick.claude.exewas still alive in Task Manager after the window closed. The repair failed with0x80073D02— "Unable to install because the following apps need to be closed: Claude". Killing the zombie in Task Manager let the next launch succeed immediately.Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.— and true to that warning, only a system reboot (17:56) let the post-boot repair complete and the app launch again.cowork-service.logshowsPersistent RPC: connection ended: failed to read length: EOFat each event, i.e. the service observing the app die.main1/2/3.logare all frozen at ~10 MiB, andmain.logstopped writing entirely two days before these crashes — the app captured zero information about them.Root cause found and filed with kernel-level evidence in #89112 — the CoworkVMService lead here is a red herring (we exonerated it: the service runs for minutes without flipping the package; the "Modified, NeedsRemediation" flip coincides to the millisecond with the GPU process loading
vk_swiftshader.dllafter a WebGPUrequestAdapter()call). Short version: the shipped MSIX contains noAppxMetadata\CodeIntegrity.cat, so when Chromium's CIG mitigation rejects that DLL (harmless in Chrome), Windows escalates it to package tampering:ntdll!LdrAppxHandleIntegrityFailureflags the package and kills the GPU process; the browser then aborts viaIntentionallyCrashBrowserForUnusableGpuProcess. That's why Repair never works — nothing is actually modified. Verified workaround until it's fixed: launchClaude.exe --disable-features=WebGPU,WebGPUService.A cross-link, plus one finding I don't think has been posted here. The
Stop-ServiceandSet-Serviceworkarounds in this thread only half work, and elevation is not what stops them.For the crash itself, #89112 has the mechanism. The package ships without
AppxMetadata\CodeIntegrity.cat, so loadingvk_swiftshader.dllgets escalated to package tampering. I confirmed that chain independently on Windows 11 23H2 build 22631 with Claude 1.34493.1.0, details in a comment over there. @SprucetheAI is right that the CoworkVMService RPC EOF is downstream of the app dying.The repair loop is a separate problem though, and it is worse than "stop the service before repairing", because you cannot durably disable the service. Its DACL:
Two ACEs. Authenticated Users gets
RPandWP, start and stop, which is whyStop-Serviceworks even unelevated. It does not getDC,SERVICE_CHANGE_CONFIG.AdministratorsandLocalSystemare absent entirely. So this fails from an elevated administrator prompt:The registry key says the same thing.
HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMServicegrantsNT AUTHORITY\SYSTEM: FullControland nothing to Administrators. That probably also explains the warning the service writes at every start:Stopping the service is not enough on its own either, because package servicing starts it and then aborts on it:
One second between the service coming up and the registration it blocks. A stop on a timer cannot win that race.
What does work is running as SYSTEM. A scheduled task with
-Principal SYSTEMthat writesStart = 4into the service key, repeating on an interval, because a successful registration resets it to2from the manifest's<desktop6:Service Name="CoworkVMService" StartupType="auto">.So one more suggested fix on top of the ones already in this thread: grant Administrators
SERVICE_CHANGE_CONFIGon this service. As shipped, a user has no supported way to turn off a LocalSystem service that runs by default, breaks their updates, and cannot configure its own recovery policy.Reproduced on a fresh install — same failure signature
Version:
Claude_1.34493.1.0_x64__pzs8sxrjxfjjcWindows install type: MSIX
Fully uninstalled Claude Desktop, deleted the old installer, downloaded a fresh installer from claude.ai, and reinstalled. Crash reproduced identically on first Cowork/CC task after reinstall — this rules out a corrupted local install as the cause.
Same
Access is deniedwarning on service recovery config, and the same RPC EOF disconnect right when Claude Code was mid-task:2026/08/25 14:25:47.876251 Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
2026/08/25 14:25:52.465882 [Server] Client connected
2026/08/25 14:25:52.806983 [Server] Client signature verified: C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\app\claude.exe (subject: Anthropic, PBC)
2026/08/25 14:25:52.808013 [Server] Client connected: user=%USERID% exe=claude.exe isDev=false
2026/08/25 14:25:52.808013 [VM] VM owner set: id=cowork-vm-4ad1cf54 sid=REDACTED
2026/08/25 14:25:52.808013 [VM] Event callbacks set
2026/08/25 14:25:52.808013 [Server] Created new VM session for %USERID%:C:\Users\%USERID%\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude
2026/08/25 14:25:52.808013 [Server] Persistent RPC: entering loop
2026/08/25 14:25:57.876390 [IdleCheck] Session %USERID%:C:\Users\%USERID%\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude: starting idle timer now
2026/08/25 14:33:35.350327 [Server] Persistent RPC: connection ended: failed to read length: EOF
2026/08/25 14:33:35.350327 [Server] Session %USERID%:C:\Users\%USERID%\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude has no active connections, idle timeout starts
Session ran for ~7.5 minutes before the RPC connection dropped mid-task. Same "Access is denied" opening the service for recovery config appears at every service start, consistently, both before and after reinstall.
sc.exe qc CoworkVMServiceconfirms the service runs asLocalSystem:SERVICE_NAME: CoworkVMService
TYPE : 210 WIN32_PACKAGED_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 0 IGNORE
BINARY_PATH_NAME : "C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
DEPENDENCIES : staterepository
SERVICE_START_NAME : LocalSystem
Happy to provide more logs/diagnostics if useful.
Adding another data point on Windows 11 with Intel integrated graphics.
Environment
Matching signature to #80468
101457950Last lines before one crash:
A browser preview had been created 7 seconds earlier.
Additional finding: main.log stops being written entirely
This may be distinct from what's already reported. After renaming the stale
main.log, I launched the app and confirmed 10 processes running at 1,408 MB. The app then crashed ~2 minutes later and produced a 35 MB Crashpad dump — but no newmain.logwas ever created. The logger never initialized. Existing logs in that directory were untouched, with timestamps two days old.This means the app can crash while producing no log output at all, which makes the documented "check main.log" guidance unreliable.
CoworkVMService: policy not honored, service cannot be disabled
With
HKLM\SOFTWARE\Policies\Claude\secureVmFeaturesEnabled = 0set and verified, the service still runs (Status: Running, StartType: Automatic) and cycles repeatedly.Stop-Serviceworks;Set-Service -StartupType Disabledfails with Access Denied even from an elevated session, presumably because MSIX owns the service.The service also logs, on every start:
Also observed: orphaned process blocks relaunch and misreports as package corruption
After a crash,
chrome-native-host(in...\LocalCache\Roaming\Claude\ChromeNativeHost\) survives. Windows then shows "You'll need to go to advanced options for Claude and select Repair," and Repair fails with "the app is currently running." ButGet-AppxPackage *Claude*reportsStatus: Ok— the package isn't damaged. Killing that one process and launching viaStart-Process "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"works immediately, no Repair needed. The process doesn't match a*claude*name filter, so it's easy to miss.Separate WER event — memory growth
Windows logged
RADAR_PRE_LEAK_64againstclaude.exe1.37937.0.0 after the app had run for roughly a day (bucket 1330937043276959777). This looks distinct from the fast GPU crash above.Not the cause, ruled out
I have the 35 MB Crashpad dump and can provide it privately to maintainers.
Hitting this same loop on Windows 11 ARM64, and I was able to pull the deployment-layer logs that explain why the built-in Repair doesn't stick and why everyone ends up reinstalling. Posting the full causal chain since the symptom here matches exactly.
Environment
| | |
|---|---|
| OS | Windows 11 Pro, build 10.0.26300 |
| Arch | ARM64 (so this is not x64-specific) |
| App | Claude Desktop 1.40609.0.0 |
| Package |
Claude_1.40609.0.0_arm64__pzs8sxrjxfjjc,SignatureKind: Developer|| Electron / Node | 42.10.0 / 24.18.1 |
| AV | Windows Defender only, no third-party AV, Controlled Folder Access off |
| Disk | 336 GB free |
Worth noting up front: the two usual explanations for MSIX remediation -- third-party AV quarantining package files, and low disk -- are both ruled out here.
It happened twice in 75 minutes with an identical signature
Both times: Cowork VM service loses RPC -> VM force-killed -> package permissions no longer match the manifest ->
NeedsRemediation-> Repair fails -> reinstall.Step 1 --
CoworkVMServiceloses its RPC connection and the VM won't shut down cleanlyFrom
C:\ProgramData\Claude\Logs\cowork-service.log:0x80070032isERROR_NOT_SUPPORTEDout of HCS -- the graceful shutdown path fails and the compute system is force-terminated every single time. I have 6+ instances of this exact block over the past week, so it is not rare.Step 2 -- every package registration has to repair ACLs on the install folder
From
Microsoft-Windows-AppXDeploymentServer/Operational:This is the key finding. Every Register operation on this package logs that ACL repair pair -- I could not find one that doesn't. The package is not being corrupted at the file-content level; the ACLs on
C:\Program Files\WindowsApps\Claude_<version>_arm64__pzs8sxrjxfjjcare drifting, and that is what flips the package toModified, NeedsRemediationand produces the "You'll need to go to advanced options for Claude and select Repair" dialog. That likely makes this the same underlying bug as #81992 and #81747.Step 3 -- the built-in Repair fails because the app's own service holds the files open
0x80073D02=ERROR_INSTALL_RESOURCES_IN_USE, "the package could not be installed because resources it modifies are currently in use." Settings -> Advanced options -> Repair does not stopCoworkVMServiceor terminate the running Cowork VM first, so the re-registration is blocked by the app's own packaged service. This is why Repair appears not to work and people conclude a reinstall is the only option -- the reinstall only succeeds because it forces a shutdown along the way.Step 4 -- the uninstall path also fails, silently
The installer attempts
RemovewithPreserveApplicationDataon a package that was not deployed in development mode, which can never succeed (0x80073CFA). It then falls back toAdd ... ForceUpdateFromAnyVersion. It recovers functionally, but that remove step fails on every install and reinstall.Suggested fixes
CoworkVMServiceand terminate the Cowork VM before anyRegistercall. This alone would make the built-in Repair actually work and eliminate most of the reinstalls in this thread.failed to configure recovery actions ... open service: Access is denied-- the service cannot set its own SCM recovery config, so once it crashes it stays down until reboot. That turns a recoverable crash into a hard failure.PreserveApplicationDataremove attempt, or guard it on development-mode deployment.Workaround that avoids reinstalling
Quit Claude, then
Stop-Service CoworkVMService, thenGet-AppxPackage -Name Claude | Reset-AppxPackage. With nothing holding the files open the re-registration succeeds and app data is preserved. Only if that fails is a reinstall actually needed.---
<sub>Diagnostics collected on the affected machine; username, machine name and SID scrubbed from log excerpts. Timestamps are local, 2026-08-29.</sub>
On-disk root cause for the "requires Advanced options → Repair" state, measured on 1.40609.0, Windows 11 Pro 26200 (MSIX install,
SignatureKind: Developer).What the package looks like after a fatal crash
Activation then redirects to the Microsoft Store instead of launching the app.
Why it is "Modified"
The app writes files inside its own signed package directory. In
…\WindowsApps\Claude_<ver>_x64__<pfn>\app\resources\:| file | CreationTime | LastWriteTime |
|---|---|---|
|
chrome-native-host.exe| 2026-08-28 10:43 | 2026-08-29 14:43 ||
cowork-svc.exe| 2026-08-28 10:43 | 2026-08-29 14:43 |The benign-looking line that appears at nearly every launch is the same operation:
Once those bytes no longer match the manifest hashes the package is permanently
Modified, and because the package is developer-signed, Store integrity validation cannot re-validate it.Every documented repair reports success and changes nothing
All run after killing
chrome-native-host.exeandcowork-svc.exeso no file locks remained:| attempt | result |
|---|---|
|
Add-AppxPackage -Register …\AppXManifest.xml -DisableDevelopmentMode| "register OK" —Statusunchanged ||
Add-AppxPackage -RegisterByFamilyName -MainPackage Claude_<pfn>| "OK" —Statusunchanged ||
winget repair --id Anthropic.Claude| "Repair operation completed successfully" — files andStatusunchanged || launch after each | 0 app processes; Microsoft Store opens instead |
Re-registration cannot help by design: registration does not restore file content, and the content is what no longer matches.
This is why the community workaround is "reboot" or "remove and reinstall, then sign in again" — a reboot only clears the file locks; it does not restore the modified files.
Suggested fix
Never write into
InstallLocationat runtime. The native-host binary should be staged into%LOCALAPPDATA%\Packages\<pfn>\LocalCache\…(or%APPDATA%\Claude\ChromeNativeHost\, which the app already uses) and registered from there. That alone would stop every fatal crash from also bricking the install.Secondary: a GPU-process death currently takes the whole app down (see #80444, where I posted evidence it reproduces with acceleration disabled, so it is not a driver issue). If the GPU process death were survivable, this package-integrity path would rarely be reached.
Note for anyone stuck right now
Nothing above recovered the package for me. What did work was installing the non-packaged build (
winget install --id Anthropic.Claude --forcepulls the.exe/Squirrel installer, not the Store package). It has no package-integrity object, so this failure mode cannot occur, and it self-updated to the same version within minutes. Back up%LOCALAPPDATA%\Packages\<pfn>\LocalCache\Roaming\Claudefirst and copyclaude_desktop_config.json,Claude Extensions, andClaude Extensions Settingsinto%APPDATA%\Claude; you will have to sign in again.<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Root cause for #85199: MSIX auto-update failure terminates Claude Desktop and leaves it in a Repair-required state</h1>
<p>I hit the same symptoms described in this issue on Windows 11 25H2 and traced them to a
failing MSIX package-servicing operation. Posting the evidence because I believe it supplies
the root cause this issue is missing — and because I think the Cowork RPC <code>EOF</code> lead in the
original report is a red herring.</p>
<h2>Summary</h2>
<p>Claude's auto-updater stages an update to <code>%TEMP%\Claude-<n>.msix</code> and asks Windows to deploy
it. The deployment fails with <code>0x80070002</code> (ERROR_FILE_NOT_FOUND) because the staged <code>.msix</code>
is not present. The updater then falls back to a remove-and-reinstall, which <strong>cannot ever
succeed</strong> because it passes <code>PreserveApplicationData</code> against a package that is not deployed
in development mode.</p>
<p>Because Windows must terminate a packaged app before servicing it, the app is killed, the
servicing then fails, and it stays closed. That is the "random quit". The package is left in
a state where <strong>Settings → Apps → Installed apps → Claude → Repair also fails</strong>, because
Repair re-enters the same deployment path.</p>
<p>This also explains why there is no crash artifact of any kind (see below) — the process is
being cleanly terminated by the OS, not faulting.</p>
<h2>Why the RPC <code>EOF</code> lead is a red herring</h2>
<p>The original report points at <code>Persistent RPC: connection ended: failed to read length: EOF</code>
followed by CoworkVMService stopping. In my logs that sequence is <strong>normal lifecycle</strong>, not a
failure. The VM service is an on-demand service that is installed on launch, stops itself when
idle, and is removed again:</p>
<pre><code>09:16:26.718318 [Server] Persistent RPC: connection ended: failed to read length: EOF
09:16:26.718318 [Server] Session <USER> has no active connections, idle timeout starts
09:17:27.692239 [Server] Stopping idle VM for session <USER> (no subscribers for 1m0s)
</code></pre>
<p><code>sc.exe qc "Claude Service"</code> returns error 1060 (service does not exist) between runs, which
is expected for this design. The repeated SCM 7045/7040 event pairs are the app registering
and deregistering that service each cycle — noisy, but not the fault.</p>
<h2>Actual evidence</h2>
<h3>1. No crash artifacts exist</h3>
<p>Checked across a 14-day window on an affected machine:</p>
<ul>
<li><code>Application</code> log: <strong>zero</strong> <code>Application Error</code>, <code>Application Hang</code>, or <code>.NET Runtime</code> events</li>
<li>WER: <code>%LOCALAPPDATA%\Microsoft\Windows\WER\ReportArchive</code> and <code>ReportQueue</code> <strong>do not exist</strong></li>
<li><code>Get-CimInstance Win32_ReliabilityRecords</code>: <strong>zero</strong> crash records</li>
</ul>
<p>A hard fault of <code>claude.exe</code> would produce at least one of these. None are produced, which is
consistent with OS-initiated termination for package servicing.</p>
<h3>2. The deployment failures</h3>
<p><code>Microsoft-Windows-AppXDeploymentServer/Operational</code>, three consecutive cycles:</p>
<pre><code>09:09:49 Id 403 Error error 0x80070002: Failure to get staging session for:
file:///C:/Users/<USER>/AppData/Local/Temp/Claude-1718667411.msix
09:09:49 Id 497 Error Error 0x80070002: Opening the Msixvc package from location
Claude-1718667411.msix failed. Please check whether the Msixvc
support services are installed.
09:09:49 Id 465 Error error 0x80070002: Opening the package from location
Claude-1718667411.msix failed.
</code></pre>
<p>Repeated identically at <code>09:13:11</code> and <code>09:19:39</code>.</p>
<p>The referenced <code>.msix</code> is absent — <code>Get-ChildItem $env:TEMP -Filter 'Claude*.msix'</code> returns
nothing.</p>
<h3>3. The fallback path is structurally broken</h3>
<pre><code>09:14:17 Id 717 Error Windows cannot remove Claude_1.40609.0.0_x64__pzs8sxrjxfjjc because
the PreserveApplicationData flag can only be used on a package that
was deployed in development mode.
</code></pre>
<p>Repeated at <code>09:20:18</code>. The package reports:</p>
<pre><code>Name : Claude
Version : 1.40609.0.0
Status : Ok
SignatureKind : Developer
IsDevelopmentMode : False
</code></pre>
<p><code>PreserveApplicationData</code> is invalid for <code>IsDevelopmentMode: False</code>, so this fallback is
guaranteed to fail on every affected install. This looks like the core defect.</p>
<h3>4. Recovery is a manual installer re-run</h3>
<p>Running the Claude installer <code>.exe</code> again produced a successful deployment:</p>
<pre><code>09:20:28 Id 613 Information Performance summary of Deployment Add operation on Package
Claude_1.40609.0.0_x64__pzs8sxrjxfjjc: Overall time: 9671 ms
</code></pre>
<p>Repair does not work as an alternative — this is a sideloaded package
(<code>SignatureKind: Developer</code>), so Windows has no source to re-acquire it from.</p>
<h2>Suspected trigger for the missing .msix</h2>
<p>Storage Sense is enabled on this machine with temp-file cleanup on
(<code>HKCU:\...\StorageSense\Parameters\StoragePolicy</code>, <code>01=1</code>, <code>04=1</code>). If it sweeps <code>%TEMP%</code>
between download and deployment, the staged package disappears and you get exactly this
<code>0x80070002</code>.</p>
<p>I want to be clear that I have <strong>not proven</strong> this is what deleted the file — the download may
simply have failed or been cleaned up by the updater itself after an earlier failed attempt.
The disk is not under pressure (807 GB free), so a space-triggered sweep is unlikely.</p>
<p>Either way, the deployment path should not depend on a file in <code>%TEMP%</code> surviving unprotected,
and the failure should not leave the package unusable.</p>
<h2>Two secondary problems worth fixing</h2>
<p><strong>a) Every VM shutdown is a forced kill.</strong> On every stop:</p>
<pre><code>[VM] Graceful shutdown failed, forcing termination:
HcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032
</code></pre>
<p><code>0x80070032</code> is <code>ERROR_NOT_SUPPORTED</code>. The Linux guest is never shut down cleanly, it is
terminated. Sustained over <code>rootfs.vhdx</code> and <code>sessiondata.vhdx</code> this carries a real
filesystem-corruption risk.</p>
<p><strong>b) SCM recovery actions cannot be armed.</strong> On every start:</p>
<pre><code>Warning: failed to configure recovery actions (a crashed service will stay down until
reboot): open service: Access is denied.
</code></pre>
<p>The service's own message states the consequence. If the VM service ever does crash, Cowork
and the bash tool stay dead until a reboot.</p>
<p><strong>c) App logging is silently dead.</strong> This corroborates the 10 MiB log observation in the
original report, though my instance failed differently — my logs are small, not at a size cap:</p>
<pre><code>%APPDATA%\Claude\logs\main.log 4.7 KB last written 29/08 03:35
%APPDATA%\Claude\logs\mcp.log 0 bytes
%APPDATA%\Claude\logs\main-window.log 0 bytes
%APPDATA%\Claude\logs\claude.ai-web.log 0 bytes
%APPDATA%\Claude\logs\ssh.log 0 bytes
</code></pre>
<p>The app was running from 09:20 on 30/08 and wrote nothing. <code>main.log</code> also reports
<code>appVersion: 1.30096.1</code> while the installed package is <code>1.40609.0.0</code>. With <code>mcp.log</code> empty,
MCP server failures are not recorded anywhere either, which makes any related diagnosis much
harder than it needs to be.</p>
<h2>Suggested fixes</h2>
<ol>
<li>Do not use <code>PreserveApplicationData</code> in the remove-and-reinstall fallback for packages
where <code>IsDevelopmentMode</code> is false — this fallback currently cannot succeed.</li>
<li>Verify the staged <code>.msix</code> exists and hashes correctly immediately before invoking
deployment; re-download rather than failing if it is gone.</li>
<li>Stage the update somewhere less volatile than <code>%TEMP%</code>, or mark it against Storage Sense
cleanup.</li>
<li>On a failed servicing attempt, leave the previously working package intact and surface a
real error, rather than leaving the app in a Repair-required state.</li>
<li>Fix log rotation / restore log writing so main-process diagnostics survive the failure.</li>
</ol>
<h2>Environment</h2>
|
-- | --
Claude Desktop | 1.40609.0.0 (Claude_1.40609.0.0_x64__pzs8sxrjxfjjc)
Install type | MSIX, sideloaded (SignatureKind: Developer)
Install location | C:\Program Files\WindowsApps\... (system volume)
OS | Windows 11 Pro 25H2, build 26200.9278, 64-bit
Locale | en-GB
CPU | AMD Ryzen AI 9 HX 370 w/ Radeon 890M
RAM | 31.3 GB
Free disk (C:) | 807.5 GB
<p>Note: unlike the original reporter, my package is on the <strong>system volume</strong> and the disk has
ample free space, yet the failure is identical — so neither of those is a precondition.</p>
<h2>Reproduction</h2>
<ol>
<li>Install Claude Desktop on Windows 11 via the MSIX installer.</li>
<li>Leave it running until the auto-updater attempts an update.</li>
<li>The app terminates with no crash dialog and no Application Error event.</li>
<li>Settings → Apps → Installed apps → Claude → Advanced options → Repair <strong>fails</strong>.</li>
<li>Inspect <code>Microsoft-Windows-AppXDeploymentServer/Operational</code> and filter for <code>Claude</code> —
observe events 403/465/497 (<code>0x80070002</code>) and 717 (<code>PreserveApplicationData</code>).</li>
<li>Re-running the installer <code>.exe</code> restores the app until the next update attempt.</li>
</ol></body></html><!--EndFragment-->
</body>
</html>