Claude DesktopがCoworkVMServiceで起動しない原因と対処法

Claude Desktop Windows版で「Repair(修復)」を実行しても、同じエラーコード0x80073D02で起動しなくなることがあります。0x80073D02でRepairが失敗する症状の引き金は、アプリ本体ではなく、パッケージに同梱されたWindowsサービスCoworkVMServiceだと報告されています。GitHubの複数のissueに、再現条件と回避策が積み上がっています。ログのコードごとに分かれる対処と、報告で効果のあった手順を扱います。

CoworkVMServiceとは何か

CoworkVMServiceは、Claude DesktopのCowork機能が使う仮想マシンをホストするWindowsサービスです。MSIXパッケージの内部に同梱され、Windowsの起動時に自動で始まるAUTO_STARTとして登録されています。サービス自体はLocalSystem権限で動きますが、自分のサービス設定を変更する権限は持っていません。

この食い違いが、Repairの失敗と更新の停止という2つの症状の根にあります。

ログのコードで見分ける5つの症状

同じ「起動しない」でも、原因と効く手が違います。ログや画面に出たコードから、自分の状況に近いものを探します。

なぜRepairを繰り返しても直らないのか

CoworkVMServiceのセキュリティ記述子(DACL)を実機で調べた報告によると、設定変更ができるのはWindowsのAppXSvcだけです。「Authenticated Users」には、開始・停止・参照などの権限しかありません。Administratorsにも、サービス自身が動くLocalSystemにも、設定変更(SERVICE_CHANGE_CONFIG)の権限がありません。

そのためサービスのログに出る次の警告は、管理者権限で実行しても消えません。

failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

自分の環境の状態は、管理者権限のPowerShellで次のコマンドを実行すると分かります。

sc.exe sdshow CoworkVMService

出力にBA(Administrators)やSY(LocalSystem)のACE(アクセス制御エントリ)が無ければ、同じDACLの問題を抱えています。報告された環境のDACLはAU(開始・停止・参照のみ)とAppXSvcの2エントリだけで、設定変更を表すDCが付くのはAppXSvcのエントリだけでした。ある報告では、昇格したPowerShellでsc.exe failureを実行してもOpenService FAILED 5: Access is deniedになっています。

Repairは、パッケージの再展開(Add)と再登録(Register)の2ステップで動きます。x64環境のログ(issue #88962)では、次の順に進んでいました。

ARM64環境の報告では、サービスの自動起動からRegisterの中断までが395ミリ秒でした。x64でもARM64でも同じ順序で、報告者は、Repairの手順そのものがこの状態を毎回決まって作っていると分析しています。

症状が軽いときはサービスの再起動を試す

終了直後の起動だけがlaunch-failedで失敗し、パッケージの状態がOkのままなら、サービスを再起動します。issue #95050では、ある日の起動18回のうち14回が失敗しました。2回に分かれた失敗は、1回目がWindowsの再起動で、2回目がサービスの再起動で収まっています。

# 管理者権限のPowerShellで実行
Restart-Service CoworkVMService

同じissueには、効かなかった手も並んでいます。パッケージを削除して入れ直しても、Add-AppxPackage -Registerで再登録しても、起動の失敗は続きました。すでに動いているアプリへの再起動要求(second-instance)は、7回のうち失敗が0回でした。

Repairを押すと、前の節のレースにもう一度入ります。症状が軽いうちは、先にサービスを再起動する方が手数が少なく済みます。ただし、サービスの再起動だけではクラッシュの繰り返しが止まらず、explorer.exeの再起動で収まったというコメントも同じissueにあります。

同じexitCode: 21でも、原因がCoworkVMServiceでない例があります。企業管理のPCを調べた投稿は、ChromiumのGPU process launch failed: error_code=21を示し、CoworkVMServiceは原因から外れたとしています。サインアウトかExplorerの再起動で一度は起動し、終了後の再起動でまた落ちる挙動です。Windows更新のKB5124008との相関を指摘しており、同じissueには、これをアンインストールすると該当端末で再起動時のクラッシュが止まったという報告もあります。

Repairが失敗したら、まずそのまま起動し直す

Repairが0x80073D02で失敗しても、その直後にアプリを普通に起動し直すと動くことがあります。ARM64環境の報告では、Repairの失敗から26秒後に何も触らず起動したところ、通常どおり開きました。同じissueには、手動でRepairをもう一度実行すると、再登録だけが成功してアプリが起動した例もあります。

この報告では、Windowsのダイアログに従ったRepairで、約250MBのパッケージを43秒かけて再ダウンロードしていました。入っているバージョンを失敗前提で取り直す動きになるので、失敗の直後は再起動を試した方が早いことがあります。

Repairが効かないときの回避策(サービス停止→手動再登録)

Repairが同じ0x80073D02で失敗するなら、サービスを止めてからパッケージを手動で再登録します。サービスが戻る前に登録を終えるので、Repairのレースに入りません。issue #88962に投稿された手順で、投稿者は初回で通ったと書いています。

# 管理者権限のPowerShellで実行
Stop-Service CoworkVMService -Force
Get-Process claude, cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force
Get-AppxPackage -Name Claude | ForEach-Object {
    Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml"
}

この手順が効くのは、レースが原因の0x80073D02です。パッケージがNeedsRemediation(0x80073CFC)になっている場合、同じ再登録は成功と表示されても起動は直りませんでした。管理者権限が要る点は、Claude Desktop Windows版のインストールと初期設定の他の手順と同じです。

「別のプログラムが使用中」は別の原因

起動時のダイアログにAnother program is currently using this fileと出て、パスにC:\Program Files\WindowsApps\Claude_...が見えるときは、症状が違います。ファイルのロックはなく、AppModel-Runtime/Adminの0x80070020(ERROR_SHARING_VIOLATION)が実体です。イベント215(コンテナ作成の失敗)と208(プロセス作成の失敗)が組で並びます。

サービスの停止・無効化については、issue #53247に両方向の報告があります。無効化(Start=4)した状態で更新が1サイクル問題なく通ったコメントがある一方、別の更新では無効化しても詰まったままだったコメントもあります。同じissueには、更新の起動を抑える回避策としてdisableAutoUpdatesポリシー(HKLM:\SOFTWARE\Policies\ClaudeにDWord値1)を使う方法も出ています。

issue #88101の投稿者は、サービスが原因だという自分の主張を取り下げました。パッケージのプロセスをすべて止めても失敗が続いたためで、更新時に残った旧バージョンのコンテナが原因だという見立てに改めています。この系統ではサービスの停止が効くとは限らないので、症状の判別が先です。

それでも直らない、NeedsRemediationになっている場合

Get-AppxPackageの状態がModified, NeedsRemediationなら、Repairも手動再登録も効きません。Modifiedは、Windowsがディスク上のファイルとマニフェストの不一致を認識したときに立つ状態ビットで、これが0x80073CFCによる起動拒否につながります。issue #91195では、WindowsのRepairとResetが、この状態では両方とも失敗しました。

ここまで来たら、いったん完全に削除してから入れ直します。

# 1. 関連プロセス・サービス・パッケージ・データを削除する
Get-Process claude, cowork-svc, parsecd, chrome-native-host -ErrorAction SilentlyContinue | Stop-Process -Force
Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
sc.exe delete CoworkVMService
Get-AppxPackage -AllUsers *Claude* | ForEach-Object {
    Remove-AppxPackage -Package $_.PackageFullName -AllUsers -ErrorAction Continue
}
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc", "$env:APPDATA\Claude" `
    -Recurse -Force -ErrorAction SilentlyContinue
 
# 2. 何も残っていないことを確認する
Get-AppxPackage -AllUsers *Claude*   # 出力が空ならOK

出力が空になったら、パッケージを入れ直します。issue #91195では、取得した.msixをAdd-AppxPackage -Path $msix -ForceApplicationShutdownで導入して、パッケージの状態がOkに戻り、CoworkVMServiceも再作成されました。削除と入れ直しの間には、Windowsの再起動を挟むのが無難だと書かれています。

削除が途中で止まると、再インストールが0x80073CF6で失敗します。issue #91195のインストーラーは、既存サービスの削除がAccess is deniedで失敗したまま上書きに進み、NeedsRemediationのパッケージを残しました。このとき「Administrator access is required」と表示されますが、管理者として再実行しても変わりません。実際の原因は、残ったパッケージの状態です。同じissueでは、クリーンな再インストールの約35分後にNeedsRemediationへ戻った例も報告されています。

組織にMSIXを配布している環境では、Claude DesktopをWindowsで一括導入する手順(MSIX)のAdd-AppxProvisionedPackageによる展開も、削除の対象に入るか確かめます。

起動ではなく「更新できない」形でも出る

CoworkVMServiceは、アプリを終了しても止まりません。パッケージを使用中のまま保持するので、「Relaunch to update」を押しても、旧バージョンでアプリが開き直るだけの形で症状が出ることがあります(issue #88101)。ログには、新パッケージを遅延登録に回す記録が残り、最後は0x80073D02で失敗します。

見落としやすいのは、Get-Process claudeが空でも、サービスがパッケージを握っていることです。更新を調べるときは、Get-Process claude, cowork-svcのように、サービスのプロセスも並べて見ます。issue #91195では、2.1.258から2.1.260への更新の前後に、サービスの停止と起動が15回以上繰り返された報告もあります。

この不具合はいつ直るのか

issue #88962と#88101は、重複としてクローズされました。#88600も#85840の重複で閉じています。#91195は、bugラベルが付いたまま開いています。修正案は、AUTO_STARTをやめ、Coworkのセッションが必要なときだけアプリがサービスを起動する、デマンド起動への変更です。#88101はStartupTypeをmanualにする形で書いています。

#91195には、パッケージ1.52386.0.0の環境で、アプリの更新(9月8日の2.1.258から2.1.260、9月11日の2.1.260から2.1.266)のたびに同じ症状が再現したという報告があります。同じissueには、昇格なしのStart-Service CoworkVMServiceで回避できるという書き込みと、名前付きパイプへの接続に失敗したときにアプリ自身がサービスを開始する修正案もあります。この記事の手順は回避策です。サービスのアクセス権限そのものを直せるのは、配布元のAnthropicだけです。

Windows版では、「Failed to spawn /usr/bin/ssh」が出てSSH接続だけ失敗する不具合のように、別の環境依存の不具合もあります。エラーメッセージとログで切り分けてから対処します。

まとめ

最初に見るのは、画面やログに出たコードです。0x80073D02、exitCode: 21、0x80070020では効く手が違い、サービスを止める手順は最後のコードには効きません。完全削除はCoworkのローカル履歴も消すため、サービスの再起動と手動再登録を試してから使います。