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

Claude Desktop Windows版で「Repair(修復)」を実行しても、しばらくすると同じエラーコード0x80073D02で再び起動しなくなることがあります。原因の大半はアプリ本体ではなく、パッケージに同梱されたWindowsサービスCoworkVMServiceです。GitHub上の複数のissueで再現条件と回避策が積み上がっているので、症状別の切り分け方と、実際に効果が確認された対処手順をまとめます。

CoworkVMServiceとは何か

CoworkVMServiceは、Claude DesktopのCowork機能が使う仮想マシンをホストするWindowsサービスです。MSIXパッケージの内部に同梱されており、Windowsの起動時に自動的に起動するAUTO_STARTとして登録されています。

サービス自体はLocalSystem権限で動作しますが、奇妙なことに自分自身のサービス設定を変更する権限は持っていません。この矛盾が、後述するすべての症状の根っこにあります。

症状で見分ける4パターン

対処法は症状によって異なります。まず自分の状況がどれに近いかを確認します。

なぜ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(アクセス制御エントリ)が含まれていなければ、CoworkVMServiceのDACLが構造的にこの問題を抱えている状態です。報告されている環境のDACLにはAU(Authenticated Users、開始・停止・参照のみ)とAppXSvcの2エントリしかなく、設定変更を意味するDCフラグはAppXSvcのエントリにしか付いていません。

Repairボタンの実体は、パッケージ再展開(Add)とパッケージの再登録(Register)という2ステップです。AUTO_STARTのサービスはAdd完了の直後に自動的に起動し直します。その数百ミリ秒後にRegisterが実行されると、Windowsは「アプリがまだ実行中」と判定し、0x80073D02で処理を中断します。つまりRepair自身が、自分を失敗させる条件を毎回作り出しています。同じissue内で、ARM64環境の報告はミリ秒単位のログでサービス起動の395ミリ秒後にRegisterが失敗する様子を記録しており、x64環境の報告でも同じ順序(Add完了直後のサービス起動→Registerの失敗)が秒単位のログで確認できます。これは外部要因とのたまたまの競合ではなく、毎回同じ形で起きる構造的な原因であることを示しています。

症状が軽いときはサービス再起動だけで直る

終了直後の再起動だけがlaunch-failedで失敗し、アプリ自体やパッケージには問題がないケースでは、サービスを再起動するだけで復帰します。Repairボタンを押す前にこちらを試す方が、リスクが小さくて済みます。

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

再起動後に通常どおり起動すれば、パッケージ自体は壊れていません。この状態で焦ってRepairを実行すると、かえって前段の0x80073D02レースを引き起こすことがあるため、まずはサービス再起動だけで様子を見ます。

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

Repairが0x80073D02で失敗しても、実はその直後にアプリを普通に起動し直すだけで動くことがあります。ARM64環境での報告では、Repairの失敗から26秒後に何の操作もせず再度アプリを起動したところ、通常どおり起動しました。

Repairの失敗そのものは、Windowsが約250MBのMSIXパッケージを再ダウンロードして再展開する処理です。すでに正しくインストール済みのバージョンを、失敗する前提で毎回ダウンロードし直しているだけなので、失敗の直後に素直に再起動する方が早いことがあります。

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

Repairを押しても同じ0x80073D02で失敗する場合は、Windows自身のRepair機能を使わず、サービスを止めてからパッケージを手動で再登録します。AUTO_STARTのサービスが復帰する前に登録を終わらせるため、Repairよりも成功率が高い手順です。

# 管理者権限の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"
}

Claude Desktop Windows版のインストールと初期設定で触れているとおり、Claude DesktopのWindows版はもともと権限まわりでつまずきやすいアプリです。この手順もコマンドはすべて管理者権限のPowerShellで実行します。

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

Get-AppxPackageで確認したパッケージの状態がModified, NeedsRemediationになっていると、Repairも手動再登録も成功しません。この状態は、パッケージの実ファイルが壊れているわけではなく、Windowsが持つ整合性判定が誤って「変更あり」と記録したまま固着している状態です。ここまで来たら、いったん完全に削除してからクリーンに入れ直します。

# 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
}
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -like "*Claude*" | ForEach-Object {
    Remove-AppxProvisionedPackage -Online -PackageName $_.PackageName
}
Remove-Item "$env:LOCALAPPDATA\AnthropicClaude", "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc", "$env:APPDATA\Claude" `
    -Recurse -Force -ErrorAction SilentlyContinue
 
# 2. 何も残っていないことを確認してから再インストールする
Get-AppxPackage -AllUsers *Claude*   # 出力が空ならOK
$msix = "$env:TEMP\Claude-fresh.msix"
Invoke-WebRequest "https://claude.ai/api/desktop/win32/x64/msix/latest/redirect" -OutFile $msix -UseBasicParsing
Add-AppxPackage -Path $msix -ForceApplicationShutdown

1と2の間でWindowsを一度再起動しておくと安全です。issueの報告によれば、CoworkVMServiceはユーザーモードの操作では解放できないカーネルロックを握ったままになることがあり、再起動を挟むことでこのロックが解放され、削除しきれなかった残骸が原因で再インストールが失敗するのを防げます。実際にこの手順を踏んだ報告では、削除後にGet-AppxPackageの出力が空になったことを確認してから再インストールし、パッケージの状態がOkに戻ってCoworkVMServiceも正常に再作成されています。

Windows向けのMSIXパッケージを組織全体に配布している環境では、Claude DesktopをWindowsで一括導入する手順(MSIX)で解説したAdd-AppxProvisionedPackageによるマシン全体展開との組み合わせも確認しておくと、個別端末での再発時に切り分けが早くなります。

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

同じCoworkVMServiceが原因で、起動失敗ではなく自動更新の失敗として症状が出るケースも報告されています。CoworkVMServiceがパッケージを常時「使用中」の状態にピン留めするため、アプリの自動更新の仕組み自体がブロックされ、「Relaunch to update」を押しても更新が適用されません。その状態で無理に更新を強制すると、今度は起動そのものが失敗するようになります。

この場合は、更新の失敗と起動の失敗を別々の不具合として切り分けず、どちらもCoworkVMServiceのAUTO_START設定が原因という前提で、上記のいずれかの対処に進みます。「更新のたびに再起動が必要になった」という変化に気づいたら、この不具合の初期症状である可能性を疑い、起動できなくなる前にサービス停止からの手動再登録を試しておく方が、後からNeedsRemediation状態に陥って完全リセットする手間より軽く済みます。

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

複数のissueが同じ根本原因を別々の症状から指摘しており、platform:windows・area:coworkのラベルで追跡されています。提案されている修正案は大きく2つです。CoworkVMServiceをAppXマニフェストの<Application>要素の外に宣言してアプリとのAUMID共有を止める方法と、AUTO_STARTをやめてCoworkセッションが必要なときだけアプリ自身がサービスを起動するデマンドスタート方式に変える方法です。

2026年9月11日にはClaude Desktop 1.52386.0.0(2.1.260から2.1.266への自動更新時)で、翌9月12日には1.52386.3.0でも同じ現象の再現が報告されています。パッケージ更新のたびに再発を確認する投稿が続いており、修正バージョンはまだ案内されていません。この記事で紹介した手順はいずれも回避策で、CoworkVMServiceのアクセス権限そのものを直せるのはAnthropic側だけです。

Windows版のClaude Desktopでは、他にも「Failed to spawn /usr/bin/ssh」が出てSSH接続だけ失敗する不具合のように、Windows固有の環境依存の不具合が報告されています。CoworkVMServiceの症状と混同しないよう、エラーメッセージとログで切り分けてから対処します。

まとめ

Claude Desktop Windows版が0x80073D02で起動しなくなったら、まず終了直後の単発失敗かどうかを確認します。単発ならサービス再起動だけで直ることが多く、Repairを繰り返す前に試す価値があります。Repairそのものが同じエラーで失敗する場合は、サービスを止めてからの手動再登録に切り替えます。パッケージがNeedsRemediationのまま固着しているときだけ、完全削除からのクリーン再インストールに進みます。根本原因はCoworkVMServiceのアクセス権限設定にあるため、ユーザー側のWindows設定を見直しても解消しません。同じ0x80073D02が出ても、原因がCoworkVMService以外にあるケースも報告されているため、ログにRepair step 2 of 2 (Register)の行があるかを先に確認し、この記事の症状と一致するかを見極めます。