CoworkVMService restart during self-update causes a brief system-wide stall that crashes/kills unrelated foreground applications

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?

When Claude Code self-updates, its CoworkVMService restarts and re-initializes the Hyper-V host compute stack (vmcompute.dll / computecore.dll / computenetwork.dll via HCS/HCN), even when no cowork VM is actually running at the time (log shows "VM already stopped, nothing to release"). This re-initialization causes a brief, system-wide stall severe enough to kill two unrelated, independent foreground applications running at the same time:

1. An app holding a global low-level keyboard hook gets killed by Windows' unresponsiveness detector (Application Hang / AppHangB1), because it can't service the hook fast enough during the stall.
2. 2. A second, unrelated app doing DXGI/Direct3D screen capture is silently terminated with zero trace anywhere: no Application Error, no Application Hang, no exit log of its own, no crash dump. It was mid-frame in a capture loop when it died.

This has happened twice, both times with second-level correlation between the service log's restart timestamp and both applications' failures. A separate, likely related crash (AccessViolationException inside D3D11CreateDevice, immediately after a sleep-resume event) happened once on the same machine with no CoworkVMService restart nearby, suggesting HCS/vmcompute activation may destabilize the GPU/display driver stack more broadly than just around this specific restart-on-update path.

Related: #88844 independently confirms (per an Anthropic support ticket quoted there) that "Claude Desktop requires the Windows Virtual Machine Platform for Cowork and relies on vmcompute and HNS" — different trigger and severity (BSOD, from a CSC/RDBSS driver conflict), but the same subsystem causing system-wide disruption.

What Should Happen?

CoworkVMService should be able to restart during a self-update without causing a system-wide stall that hangs or crashes unrelated foreground applications. If HCS/vmcompute re-initialization is required on every restart even when no VM is running, ideally that work should be deferred or made non-blocking so it doesn't interfere with the rest of the system.

Error Messages/Logs

cowork-service.log, incident 2 (2026-08-26 12:58:39–40), the one with the tighter timeline:

2026/08/26 12:58:39.528208 Service stop requested
2026/08/26 12:58:39.531795 Warning: failed to disarm recovery actions for this stop: open service: Access is denied.
2026/08/26 12:58:39.532805 [VM] VM already stopped, nothing to release
2026/08/26 12:58:39.532805 Service stopped.
2026/08/26 12:58:40.342943 Starting CoworkVMService as Windows service
2026/08/26 12:58:40.344977 [HCS] Initializing HCS DLLs...
2026/08/26 12:58:40.346965 [HCS] vmcompute.dll loaded successfully
2026/08/26 12:58:40.348473 [HCS] computecore.dll loaded successfully
2026/08/26 12:58:40.348473 [HCN] Initialized HCN API from computenetwork.dll
2026/08/26 12:58:40.431816 [Server]   Package: Claude_pzs8sxrjxfjjc (...\Claude_1.37937.1.0_x64__pzs8sxrjxfjjc)

Windows Application log, same second:
26/08/2026 12:58:39  Application Hang (1002): OopsLayout.exe stopped interacting with Windows and was closed.
26/08/2026 12:58:39  Windows Error Reporting (1001): Fault bucket ..., Event Name: AppHangB1

The second app (our own DXGI capture tool) stopped logging its 5-second heartbeat in the same second, with no crash/exit entry of its own anywhere.

Incident 1 (2026-08-25 20:01:35–36) shows the identical pattern: [HCS] vmcompute.dll loaded successfully at 20:01:36.688031, Application Hang for the same hook-holding app at 20:01:35.

Separately, the same day (2026-08-26 11:47:25), immediately after a resume-from-sleep event, our DXGI app hard-crashed:
Exception code: 0xc0000005
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at Vortice.Direct3D11.D3D11.D3D11CreateDevice_(...)
No CoworkVMService restart is logged near that timestamp.

Steps to Reproduce

Not a deliberate, on-demand repro — this was found by correlating logs after the fact, not triggered intentionally. What we observed both times:

1. Have at least one other Windows app open that either holds a global low-level keyboard hook, or is doing DXGI/Direct3D screen capture in a loop (in our case: an input-remapping utility, and a separate ambient-lighting app doing desktop duplication).
2. 2. Leave Claude Code running in the background long enough that it self-updates and CoworkVMService restarts (in cowork-service.log: "Service stop requested" → "Starting CoworkVMService as Windows service" → HCS/vmcompute re-init).
3. 3. Check Windows Event Viewer (Application log) for the same second as the restart: an Application Hang (1002) / AppHangB1 for the hook-holding app.
4. 4. Check the other app's own log: it will have stopped writing in the same second, with no error of its own anywhere.

To look for this independent of us: search Application/System event logs for CoworkVMService restart timestamps (Application log, provider "CoworkVMService", messages containing "starting") and diff them against Application Hang (1002) / Application Error (1000) timestamps for anything else running at the time.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.37937.1.0 (desktop app package version, confirmed from cowork-service.log and the MSIX install path; this machine runs the desktop app, not the npm CLI, so claude --version isn't available to run)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Searched existing issues before filing, for "cowork", "vmcompute", "hang", "stall". Closest matches, both distinct from this report:

• #88844 — confirms the same vmcompute/HCS subsystem is a known source of system-wide disruption (cited above), but the trigger and symptom are different: a BSOD from a CSC/RDBSS driver conflict, not a brief stall on a routine restart.
• #88673 — a different symptom of the same self-update process ("app is corrupt, needs repair" after a silent update), not the vmcompute stall reported here.

Neither describes the specific pattern reported here: a routine CoworkVMService restart during self-update, with no VM active, stalling the system long enough to hang or silently kill unrelated foreground applications.