[BUG]Claude Desktop repeatedly crashes and requires “Advanced Options → Repair” on Windows

[romers352]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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 release

Steps to Reproduce

1. Install Claude Desktop on Windows.
2. Launch Claude Desktop.
3. Use Claude normally.
4. After some time, Claude stops/crashes.
5. Windows displays the message asking to use Advanced options → Repair.
6. Reinstall Claude.
7. Launch Claude again.
8. The issue eventually returns.
9. Check C:\ProgramData\Claude\Logs\cowork-service.log.
10. Observe that CoworkVMService initializes successfully and Claude connects.
11. Observe that the persistent RPC connection later ends with:
    "failed to read length: EOF"
12. 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.

[kipertech]

getting the same issue, it only started happening today

[romers352]

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:

• Claude Desktop: 1.26832.0.0
• Windows 11 Home 64-bit
• AMD Ryzen 7 5700G
• 24 GB RAM
• Integrated AMD Radeon Graphics
• Claude Browser MCP
• CoworkVMService enabled

[romers352]

getting the same issue, it only started happening today

it is claude brower mcp

[Amrobillions]

yess, same here

[1bbqfreak-ui]

+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

[Methode7H]

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

[SprucetheAI]

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

Name      : CoworkVMService
DisplayName: Claude
StartName : LocalSystem
StartType : Automatic
State     : Running
PathName  : "C:\Program Files\WindowsApps\Claude_1.28929.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

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 ForceTargetApplicationShutdownOption shuts down app processes, not services. So the register step fails with 0x80073D02 (ERROR_INSTALL_RESOURCES_IN_USE), Windows falls back to offering Repair, and Repair hits the same wall.

Timeline from Microsoft-Windows-AppXDeploymentServer/Operational

02:57:40  603  Add 1.28929.0.0, Options NormalPriorityRequest and DeferRegistrationWhenPackagesAreInUse
02:58:07  400  Add finished successfully              <- new package staged, old one still registered
07:25:48  401  Register FAILED 0x80073D02
07:25:48  404  "Unable to install because the following apps need to be closed Claude_1.26832.0.0_x64__pzs8sxrjxfjjc"
11:16:56  603  RegisterByPackageFullName 1.26832.0.0, Options ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
11:17:25  400  Register OK
11:17:26  401  Register FAILED 0x800706BE (RPC_S_CALL_FAILED)
11:17:26  404  "Unable to install because of an unknown error 0x800706BE in determining which apps need to be closed"
--- user-initiated restart ---
11:20:09  400  Register 1.28929.0.0 OK
11:28:54  603  eight RepairAppRegistration cycles begin
11:29:35  400  ...all eight report success
--- user-initiated restart ---
11:34:27  603  RepairPackageOperation -> re-Add of the msix
11:35:52  400  Add OK
11:35:53  401  Register FAILED 0x80073D02
11:35:53  404  "Unable to install because the following apps need to be closed Claude_1.28929.0.0_x64__pzs8sxrjxfjjc"

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:

8107  Error  Illegal non-AppStore or non-AppInstaller package integrity validation attempted for package Claude_1.28929.0.0_x64__pzs8sxrjxfjjc. Flags: 0x0
8104  Error  Failed to set the Trust Label on package Claude_1.28929.0.0_x64__pzs8sxrjxfjjc with flags 0x0. Error: 0x80070057
728   Warn   error 0x80070015: Unable to notify pre-launch service for app Claude_pzs8sxrjxfjjc!Claude install/uninstall

Two corrections to the original diagnosis

The Persistent RPC: connection ended: failed to read length: EOF line is not the failure. In C:\ProgramData\Claude\Logs\cowork-service.log it 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 by HcsShutdownComputeSystem 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.log rotates here, it does not stop at 10,485,760 bytes:

main.log    54,755
main1.log   14,603,694
main2.log   20,893,127
main3.log   13,009,849
main4.log   11,763,903

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.DMP and LiveKernelReports are all empty. If you see a burst of WER BlueScreen / LiveKernelEvent entries in the Application log right after boot, check the creation dates on C:\ProgramData\Microsoft\Windows\WER\ReportQueue before blaming them. Mine span 2025-12-04 to 2026-08-04 and were simply flushed to the upload queue at boot. Crashpad\reports is also empty, and mcp.log is 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:

Stop-Service CoworkVMService
Get-Process claude,cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force
Add-AppxPackage -RegisterByFamilyName -MainPackage Claude_pzs8sxrjxfjjc

After that, Get-AppxPackage Claude reports 1.28929.0.0 / Status: Ok.

Suggested fix

Any one of these breaks the cycle:

1. Install cowork-svc.exe outside the versioned package directory, so an update never has to replace a path a running service holds.
2. Stop CoworkVMService in the update pre-flight and start it after registration, rather than relying on ForceTargetApplicationShutdownOption, which does not touch services.
3. Have the service exit on DeferRegistrationWhenPackagesAreInUse staging 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.

[stpsihologi6-boop]

Preflight Checklist

• 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 release

Steps to Reproduce

1. Install Claude Desktop on Windows.
2. Launch Claude Desktop.
3. Use Claude normally.
4. After some time, Claude stops/crashes.
5. Windows displays the message asking to use Advanced options → Repair.
6. Reinstall Claude.
7. Launch Claude again.
8. The issue eventually returns.
9. Check C:\ProgramData\Claude\Logs\cowork-service.log.
10. Observe that CoworkVMService initializes successfully and Claude connects.
11. Observe that the persistent RPC connection later ends with:
    "failed to read length: EOF"
12. 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.

[stpsihologi6-boop]

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.

[luciofreitas]

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)

[romers352]

this claude brower mcp issue , say do not use brower mcp to claude when working project file insted use curl

[Farooq4414]

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, NeedsRemediation within minutes. A clean reinstall corrupts
immediately on deployment.

Ruled out:

• chkdsk C: /scan - no problems, no bad sectors
• sfc /scannow - no integrity violations
• Add-AppxPackage -Register against the on-disk manifest completed
  successfully but did not clear the status
• Not a stale ImagePath; the registered binary path matches the installed version

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 hns or vmcompute. As an AUTO_START service it races both
at 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 hns was 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.