Claude Desktopが起動しない0x80070020エラーの原因と対処法

Windows版Claude Desktopを更新すると、「Another program is currently using this file」のダイアログが出て起動しないことがあります。日本語の画面では「このファイルはほかのプログラムで使われています」のような文言で出る環境もあるとみられます。ファイルがロックされているように読めますが、ロックされているファイルはありません。GitHub Issueの報告では、原因は旧バージョンのAppXコンテナ(パッケージアプリを分離する実行環境)が消えずに残ることだと突き止められています。

残している犯人はひとつではありません。Gitの常駐プロセス、Androidのadb、MCPサーバー、バックグラウンド監視のtailなど、Codeタブのセッションが起動した子プロセスが次々と報告されています。犯人ごとに直し方が違うので、再起動の前に切り分けられます。イベントIDが216で0x80070057なら別の原因で、0x80070057の起動失敗を見てください。

起動しないときに最初に試す3手順

再起動の前に、次の順で試すと切り分けられます。

1. Ctrl+Shift+Escでタスクマネージャーを開き、「詳細」タブでgit.exe・tail.exe・adb.exe・node.exeなどの孤立プロセスを探して終了する
2. 見つからなければ、サインアウトしてサインインし直す
3. それでも直らなければ再起動する

1の詳しい手順と、犯人ごとの直し方は次の節以降にあります。

「別のプログラムが使用中」の正体は0x80070020

ダイアログの文言はWin32エラー32番(ERROR_SHARING_VIOLATION)の生の文字列です。実際の失敗はMicrosoft-Windows-AppModel-Runtime/Adminログのイベント215と208に、HRESULT 0x80070020として記録されます。

Event 215: 0x80070020: Cannot create the Desktop AppX container for package
           Claude_<新バージョン>_x64__pzs8sxrjxfjjc because an error was
           encountered converting the job.
Event 208: 0x80070020: Cannot create the process for package Claude_<新バージョン>_...
           because an error was encountered while configuring runtime. [LaunchProcess]

失敗するのは「ジョブをサイロ(Windowsがプロセスをコンテナ単位に隔離する実行境界)に変換する」ステップです。Sysinternalsのhandle64でClaude.exeやパッケージフォルダーを調べても、ハンドルを握っているプロセスは出てきません。更新から失敗までの流れは次のとおりです。

この仕組みはIssue #73107で特定されました。ジョブをクエリしたところ、メンバーは更新の数時間前にセッションが起動した昇格済みのツールインストーラーと、そのconhostの2つだけでした。この2つをtaskkillすると再起動なしで起動が回復しています。

まずタスクマネージャーを確認する

再起動せずに回復した報告の多くは、孤立した子プロセスを終了する方法です。

1. Ctrl+Shift+Escでタスクマネージャーを開き、「詳細」タブで名前列を確認します
2. 以前のClaudeセッションが起動した可能性のあるプロセスを探します。報告に出てくるのはgit.exe・tail.exe・grep.exe・sleep.exe・node.exe・python.exe・adb.exeなどです
3. 今使っていないものを終了します。終了できない場合は、タスクマネージャーを管理者として実行し直します
4. Claude Desktopを再度起動します

どの子プロセスが残っているかで直し方が変わる

報告されている犯人は次のとおりです。

MCPサーバーは、Claude Code本体とともにジョブのメンバーになっていたと報告されています。tailとgrepの組は、Claude Code自身のMonitorツールが起動した監視で、セッションが終わっても残りました。

この2行の報告には、起動ではなく更新の登録時に0x80073D02で失敗した型も含まれます。旧コンテナを子孫が保持する原因は共通で、強制登録が完了したかどうかでエラーが変わるという説明です。0x80073D02側はCoworkVMServiceの0x80073D02エラーにあります。

パッケージ側にも2つの原因が報告されています。1つはパッケージ同梱のCoworkVMServiceで、LocalSystemの自動起動サービスとしてセッション0でコンテナを先に作り、対話セッションのClaude.exeが自分のコンテナを作れなくなるという説明です。一方で、起動が失敗した同じ秒に、このサービス自身のコンテナ(セッション0)は問題なく作られていたという観察もあり、衝突はユーザーセッション単位で起きるとされています。sc config CoworkVMService start= disabledは管理者のシェルでも「アクセスが拒否されました」になります。Stop-Serviceで止めても、名前付きパイプのトリガーで再起動するため、効かないことがあります。サービスを止めても起動が回復しなかった対照実験も、別の報告者から出ています。

もう1つは、コンテナのレジストリハイブ(User.dat・UserClasses.dat)をカーネルが保持するケースです。Issue #53247では、サインアウトとサインインで解放されたと報告されています。プロセス一覧に犯人が見当たらないときは、このケースを疑います。

git fsmonitorとgpg-agentは名前で見つけて終了する

特定が進んでいる個別のケースが、Gitのfsmonitor(ファイルシステム監視デーモン)です。Issue #91763によると、core.fsmonitorが有効なリポジトリでCodeタブからgit statusなどを実行すると、Gitがgit fsmonitor--daemon run --detachを起動します。親を持たず、パッケージ識別情報もないため、通常のプロセス一覧では見つけにくくなります。

コマンドラインで絞り込めば、該当のプロセスを特定できます。

Get-CimInstance Win32_Process -Filter "Name='git.exe'" |
  Where-Object CommandLine -like '*fsmonitor--daemon*' |
  ForEach-Object { Stop-Process -Id $_.ProcessId }

このプロセスはユーザー権限で動いているため、管理者権限は要りません。終了と同時に古いコンテナが消えます。再起動もサインアウトも昇格も不要で、イベント217(Destroyed Desktop AppX container)が旧コンテナ消滅の合図として報告されています。同じリポジトリで更新のたびに繰り返すなら、予防として次のコマンドで無効化する選択肢があります。報告では、開いたリポジトリごとにgit config --unset-all core.fsmonitorで設定を外す手も挙がっていますが、これで塞げるのは経路の1つだけという指摘もあります。

git config core.fsmonitor false

署名付きコミットを使っていると、GnuPGのデーモンが残ることがあります。Issue #91763には、gpg-agentがkeyboxdとscdaemonを再起動するため、gpg-agentを先に終了する必要があるという報告があります。

Stop-Process -Name gpg-agent -Force
Stop-Process -Name keyboxd, scdaemon -Force -ErrorAction SilentlyContinue

Androidデバッグ用のadbサーバーが原因だった報告もあります。デバッグの接続が一時的に切れますが、使用中でなければ次のコマンドで解放できます。

adb kill-server

CoworkVMServiceが犯人と思われるときは、管理者権限のPowerShellで止めてから起動を試します。

Stop-Service CoworkVMService -Force

「修復」や再インストールでは直らない理由

パッケージを修復するRegisterByPackageFullName(RepairAppRegistrationOption付き)や、Add-AppxPackage -Registerでのマニフェスト再登録は、ACLの修復に成功したと報告するだけで、0x80070020を解消しません。原因は古いコンテナジョブの残留であり、パッケージの破損ではないためです。Get-AppxPackageの結果もStatus: Okのままです。

見落としやすい点がもうひとつあります。コンテナジョブのメンバーになる条件は「パッケージ識別情報を持つこと」ではなく、「そのジョブに所属していること」です。ある報告では、正常に動いているコンテナで25個のメンバーのうち9個がClaude.exeではなく、すべてGetPackageFullNameが識別情報なしと返しました。tasklist /appsのようなパッケージ識別情報ベースの確認では、犯人が見えません。

それでも直らないときは再起動かサインアウト

タスクマネージャーでの終了を試しても直らず、CoworkVMServiceやカーネルのハイブが原因のときは、ユーザー権限のプロセス終了では解放できません。多くの報告では再起動で回復しています。一方で、再起動後も起動しなかった例と、次の更新で再発した例もあります。ハイブが原因の#53247では、サインアウトだけで解放されました。

なぜ更新のたびに起きるのか

更新は、本人が操作していない間に走ることがあります。複数の報告に、アプリのmain.logに[stealth-update] Triggering stealth update after idle timeoutが記録され、そのあとbeforeQuitForUpdateで終了して起動できなくなった例が出ています。更新の仕組みとして、アップデーターは新ビルドをDeferRegistrationWhenPackagesAreInUseで配置し、あとからForceApplicationShutdownOption付きのRegisterByPackageFamilyNameを自分で呼ぶと報告されています。ある報告者は、最後のセッション書き込みから約10分後、複数のサブエージェントを動かしている最中に、強制的な再起動が走ったと書いています。

別の報告者は、同じマシンで更新が成功した回と失敗した回を比べています。違いは終了時のログにありました。

1台のマシンの観察なので、一般的な確率までは言えません。PTYのシェルは終了時に片付けられても、背景で動くtail | grepのような子孫は残るという報告もあります。

予防としては、更新前にCodeタブのセッションを終えておき、git config core.fsmonitor falseのように避けられる犯人は設定で外すことになります。報告では、「再起動して更新」の前にClaude Codeのセッションを閉じる、常駐させたいものはexplorer.exeやタスクスケジューラー経由で起動する、という回避も挙げられています。MCPサーバーやMonitorツールの子孫には、利用者側で外せる設定は報告されていません。

報告の経過と、提案されている修正

この現象は、1つの原因ではなく、新しい犯人が見つかるたびに同じ症状として報告されてきました。

Issueでは複数の対応が提案されています。#91763が挙げるのは3点です。Claude Codeの子プロセスをCREATE_BREAKAWAY_FROM_JOBでジョブから切り離すこと、強制終了の前に残りのメンバーを終了すること、失敗時に実際のエラーを表示することです。#73107は、SYSTEM権限で終了時に子孫を一掃する案と、0x80070020のときに古いジョブのメンバーを終了して再試行する案を挙げています。

切り離しには異論もあります。コンテナに属していれば残った子孫を特定できますが、切り離すと特定できなくなり、サイレントなデーモンの蓄積になるという指摘です。複数のコメントがこの点を挙げています。

Claude Codeの起動やDesktop周りのほかの症状は、Claude Code Desktopが起動しない・403エラーの対処法にあります。起動の前、インストール段階で0x80073CF9が出て止まる場合は、MSIXに紛れたpriconfig.xmlの確認方法を参照してください。

よくある質問

Coworkを使っていなくても起きるか

起きます。CoworkVMServiceはパッケージに同梱されたサービスで、自動起動の設定になっています。「Coworkを使っていないのに起きた」という報告も出ています。

ターミナルから使うClaude Codeでも同じことが起きるか

報告されている仕組みで旧コンテナを保持するのは、デスクトップアプリが起動したセッションの子孫です。ターミナルから起動したClaude Codeは、その子孫ではありません。MSIXパッケージで配布されるのはデスクトップアプリです。CLIの公式インストール手順はネイティブインストーラーが推奨で、WinGet・Homebrew・npmなども選べます。npmパッケージも同じネイティブバイナリを入れます。組織での一括導入はClaude DesktopをWindowsで一括導入する手順(MSIX)にあります。個人利用の初期設定はClaude Desktop Windows版のインストールと初期設定です。

Windows 10でも起きるか

Windows 10 Pro(19045)でMonitorツールのtailとgrepが原因の報告があります。ただし起動時ではなく、更新の登録時に0x80073D02で失敗した型で、旧コンテナを子プロセスが保持する点は同じです。0x80070020の報告の多くはWindows 11の26100や26200です。

まとめ

「Another program is currently using this file」は、ファイルのロックではなく、旧バージョンのコンテナに残った子プロセスのサインです。再起動の前に、タスクマネージャーでgit・tail・adbなどの孤立プロセスを探すと、直ることがあります。外せる犯人は設定で外し、外せないMCPサーバーやMonitorの子孫は、更新が走る前にCodeタブを閉じておくと避けられます。