[BUG] conhost.exe AppHangB1 crash during CoworkVMService shutdown on session idle-timeout

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Aug 7, 2026

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?

Environment

  • Claude Version: 1.26832.0.0
  • Host OS: Windows 11 Pro 64-bit (Build 26200.8973)
  • Virtualization: Hyper-V / HCS backend, Virtual Machine Platform enabled
  • Service: CoworkVMService (cowork-svc.exe)

Problem

When Claude Desktop disconnects/closes and CoworkVMService gracefully shuts
down the active VM session, the teardown of the virtual console named pipe
triggers a blocking I/O hang in conhost.exe (Windows Console Window Host).
Windows flags it as unresponsive and force-terminates it — logged as
AppHangB1 (Event ID 1002).

Trigger sequence

  1. Client disconnects — cowork-svc.exe gets an EOF read failure:

[Server] Persistent RPC: connection ended: failed to read length: EOF

  1. Session goes idle, idle timeout starts, then service stop is requested:

Service stop requested / Shutdown signal received... / Stopping server...

  1. The named pipe (\\.\pipe\cowork-daemon-console-cowork-vm-*) linked to the

guest shell is torn down abruptly — no graceful EOF handshake sent first.

  1. conhost.exe attached to that pipe handle stays blocked on read/write.
  2. Windows force-closes it: AppHangB1.

Evidence (cowork-service.log, timestamps line up to the second with the WER report)

2026/08/08 04:42:28.994207 [Server] Persistent RPC: connection ended: failed to read length: EOF
2026/08/08 04:42:28.994207 [Server] Session ...has no active connections, idle timeout starts
2026/08/08 04:43:23.145829 Service stop requested
2026/08/08 04:43:23.145829 Shutdown signal received...
2026/08/08 04:43:23.145829 [Server] Stopping server...
2026/08/08 04:43:23.145829 [Server] Stopping VM for session...
2026/08/08 04:43:23.145829 [VM] VM already stopped, nothing to release
2026/08/08 04:43:23.145829 [Server] Server stopped
2026/08/08 04:43:23.145829 Service stopped.

Report.wer (Event ID 1001/1002), same second (2026-08-08 04:43:23):
EventType=AppHangB1
NsAppName=conhost.exe
Sig[1].Value=10.0.26100.8972 (conhost.exe version)
Sig[4].Value=2097152 (Hang Type)

Suggested fix

VM lifecycle manager in cowork-svc.exe should send a clean terminal
disconnect/shutdown signal down the VirtioSerial channel (Port 0) to flush
the named pipe buffers and release conhost.exe's thread locks before
closing the pipe handles, instead of tearing the pipe down abruptly.

Reproduction note

Observed twice in one session, both times shortly after the Browser-pane
preview tool spawned a local dev server + browser tab and then went idle
between tool calls — consistent with the idle-timeout trigger above, not
tied to any specific app code.

What Should Happen?

CoworkVMService shutdown/idle-timeout teardown should not hang or crash
conhost.exe — the named pipe teardown should complete cleanly with no
Windows Error Reporting event.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

  1. Start a Claude Code session that uses the Browser-pane preview tool

(spawns a local dev server + browser tab via the VM).

  1. Let the tool sit idle between calls for roughly a minute or more

(matches the ~55s gap between the logged EOF and "Service stop requested"
in the evidence below).

  1. Let the VM session idle-timeout and the service perform its shutdown.
  2. Not reliably deterministic — observed twice in one session under this

pattern, no confirmed single-command repro yet.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.220

Claude Code Version

2.1.224

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

claude_apphang_bug_report.md

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗