このエラーは、Windows 上の Claude Desktop / Cowork で isolated Linux environment が起動できなかったときに出ています。今回の症状クラスタでは、同じ文言を出す issue が 2 件ありました。ひとつは #98613、もうひとつは #88921 です。
まず、あなたのケースがどちら寄りかを切り分けるのが先です。
#98613 では、Windows で Claude Desktop を複数インスタンス使っていて、--user-data-dir が異なる状態だと、後から起動したほうだけ VM の作成に失敗しています。issue 本文では、Cowork の VM ID が Windows の user SID のみから派生し、CoworkVMService 側は SID と Claude Desktop の data folder の両方で session を分けている、と説明されています。その結果、同じ ID の Hyper-V compute system を 2 つ作ろうとして衝突する、という筋書きです。
#88921 は少し違います。こちらは Windows の CoworkVMService 自体は起動し、HCS/HCN の初期化や named pipe server の開始までは進むのに、クライアント接続を受けるところで止まったままになります。issue では configure 呼び出しも VM 作成ログもエラーも出ず、ログが [Server] Client connected で埋まり続ける、と報告されています。
手元で確認できている一次情報は環境情報だけです。ここから先の再現結果や回避策は、今回は実測できていません。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-02T08:55:02+09:00
なので、現時点で確実に言えるのは次の2点です。
1つ目は、この文言は Windows 側の isolated Linux workspace の起動失敗を指していること。
2つ目は、少なくとも公開 issue 上では、複数インスタンスの VM ID 衝突らしきケースと、サービスが接続ループのまま進まないケースの 2 系統が見えていることです。
もしあなたの環境が Windows で、Claude Desktop を複数の --user-data-dir で同時に使っているなら、#98613 にかなり近い可能性があります。
逆に、単一インスタンスでも毎回同じエラーが出て、サービス側のログが接続待ちのまま進まないなら、#88921 の系統かもしれません。
ただし、どちらも issue ベースの推測であって、こちらでは実機検証できていません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-02T08:55:02+09:00