Claude Media
Claude Desktopが0x80070020で起動しないときの原因と対処法
ClaudeClaude CodeTips

Claude Desktopが0x80070020で起動しないときの原因と対処法

Windows版Claude Desktopが更新後に「Another program is currently using this file」で起動しない原因はAppXコンテナの残留です。再起動なしで直す手順を整理しました。

読了目安 約11分

Windows版Claude Desktopを更新すると、「Another program is currently using this file」というダイアログで起動しなくなることがあります。ファイルがロックされているように読めますが、実際にロックされているファイルはありません。GitHub Issueでの長期にわたる調査で、原因はWindowsのAppXコンテナ(パッケージアプリを分離する実行環境)が旧バージョンのぶん残り続けることだと特定されています。再起動以外にも直す方法があり、原因パターンによって対処が変わります。

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

ダイアログの文言はWin32エラー32番(ERROR_SHARING_VIOLATION)の生の文字列で、ファイルロックの有無とは関係ありません。実際に記録されるのはMicrosoft-Windows-AppModel-Runtime/Adminのイベント215と208で、いずれもHRESULT 0x80070020です。

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

失敗しているのは「ジョブをサイロ(Windowsがプロセスをコンテナ単位に隔離する実行境界)に変換する」ステップです。旧バージョンのAppXコンテナジョブ(Container_Claude_<旧バージョン>_...)がカーネルの名前空間に残っています。新バージョンは同じユーザーセッション向けにコンテナを作ろうとして、この残留ジョブと衝突します。GitHub Issue #73107では、このコンテナジョブを直接クエリしてPIDを特定し、それを終了すると再起動なしで即座に起動が回復することが確認されています。

原因は主に3パターンある

古いコンテナジョブが残る理由は1つではありません。報告を突き合わせると、パターンごとに切り分け方と対処が変わります。

原因手がかり効く対処
Claude Codeセッションの子プロセスが生き残っている手がかりタスクマネージャーにgit.exe・tail.exe・node.exe・wsl.exeなどの孤立プロセスが見える効く対処昇格済みの子プロセスは管理者として実行したタスクマネージャーやPowerShellから終了。fsmonitorデーモンは管理者権限なしで終了できる
パッケージ同梱のCoworkVMServiceが新旧のコンテナを取り合う手がかりサービスがセッション0で自動起動しており、sc configが「アクセスが拒否されました」になる効く対処サービスを一時停止するか、諦めて再起動する
Windowsのレジストリハイブ(User.datなど)をカーネルが保持している手がかりプロセス一覧に該当プロセスが見当たらない効く対処サインアウトでも解放されることがある

コンテナジョブのメンバーになった子プロセスの一部は、管理者権限のないClaude Desktop本体から起動していても昇格して実行されており、管理者権限のない親プロセスからは終了できません。

再起動せずに直す — まずタスクマネージャーを確認する

多くの報告は1つ目のパターンで、次の手順で再起動なしに回復しています。

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

Androidデバッグ用のadbサーバーが原因になっていた報告もあります。使用中でなければ次のコマンドで解放できます。

adb kill-server

CoworkVMServiceが原因と思われる場合は、管理者権限のPowerShellで一時停止してから起動を試します。ただし、効かないこともあります。

Stop-Service CoworkVMService -Force

git fsmonitorが原因なら1コマンドで切り分けられる

もっとも再現しやすい個別ケースが、Gitのfsmonitor(ファイルシステム監視デーモン)です。Issue #91763によると、リポジトリでcore.fsmonitorが有効なとき、Desktop内の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 }

このプロセスはユーザー権限のままで起動しているため、管理者権限なしで終了できます。終了と同時に古いコンテナが消え、次の起動で成功します。

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

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

タスクマネージャーやGet-Processだけで判断しづらいのも同じ理由です。コンテナジョブのメンバーになる条件は「パッケージ識別情報を持つこと」ではなく「そのジョブに所属していること」です。Gitのヘルパー・MCPサーバー・シェルのようなパッケージ外のプロセスでも、条件を満たせば残留の原因になります。ある報告では、健全に動いているコンテナでも25個のジョブメンバーのうち9個がパッケージ識別情報を持たない子プロセスでした。tasklist /appsやGetPackageFullNameベースの確認だけでは、こうした残留プロセスを見落とします。

それでも直らないときの最終手段

タスクマネージャーでの終了を試しても直らない場合、CoworkVMServiceのパッケージフォルダーへの参照やレジストリのカーネルハイブが原因の可能性があります。この2つはユーザー権限のプロセス終了では解放できません。最終手段は再起動です。いずれの原因パターンでも、再起動はコンテナジョブを保持しているプロセスを一掃するため、確実に効きます。レジストリハイブが原因のケースでは、サインアウトだけで解放された報告もあります。

次の更新で再発させないための予防策

アイドル状態が続いたあとに更新が走ったというログが報告に含まれています。操作していない間に更新が走ると、開いたままのCodeタブのセッションが巻き込まれることがあるため、意図的に触っていなくても発生し得ます。この現象を避けるための予防策としては、次の2つが報告の中で効果を確認されています。

  • アプリを更新前に終了する際、Codeタブのセッションを手動で閉じてから終了する。バックグラウンドのtail・grepパイプラインや開発サーバーは、セッションの終了時に一緒には終了されないことがあります
  • 更新の信頼性を優先するリポジトリでは、Desktop内のCodeタブで扱う前にgit config core.fsmonitor falseでfsmonitorを無効化しておく
git config core.fsmonitor false

修正版は出ているか

Issue #73107は2026年7月2日に報告され、2026年9月22日の報告まで同じ現象が継続しています。関連するIssue #91763を含め、複数の関連issueが同じ0x80070020の症状を報告していますが、いずれも公式の修正版は出ていません。

過去に近い症状を扱ったIssue #46179(CoworkVMServiceのファイルロック)はクローズ済みです。ただしCoworkVMServiceがパッケージフォルダーの内側から動き続ける構造自体は変わっていないため、根本的な解決には至っていません。Issueの本文では2つの対応が提案されています。1つはClaude Codeが生成する子プロセスをコンテナジョブから切り離して起動する対応(CREATE_BREAKAWAY_FROM_JOB)、もう1つは起動失敗時に古いコンテナのメンバーを自動的に片付けて再試行する自己修復の実装です。

Claude Codeの起動・Desktopまわりのそのほかの症状(403エラーや画面が固まる症状など)はClaude Code Desktopが起動しない・403エラーの対処法にまとめています。

よくある質問

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

起きます。CoworkVMServiceはパッケージに同梱されたWindowsサービスとして自動起動する設定になっており、Cowork機能を使っていないユーザーでも稼働します。実際に「Coworkを使っていないのに発生した」という報告があります。

Claude Code CLI単体(npmインストールなど)でも同じ現象が起きるか

起きません。この不具合はWindows版Claude DesktopがMSIX(AppX)パッケージとして配布されていることに起因するコンテナ管理の問題です。CLI単体のClaude Codeはネイティブインストーラーで配布されており、AppXコンテナの仕組みを使わないため、この0x80070020エラーの対象にはなりません。組織で一括導入する場合のMSIXパッケージの扱いはClaude DesktopをWindowsで一括導入する手順(MSIX)、個人利用でのインストールと初期設定はClaude Desktop Windows版のインストールと初期設定にまとめています。

まとめ

Windows版Claude Desktopが更新後に「Another program is currently using this file」で起動しないときの正体は、ファイルロックではなく旧バージョンのAppXコンテナジョブの残留です。タスクマネージャーで孤立したプロセス(特にGitのfsmonitorデーモン)を探して終了すると、多くの場合は再起動なしで直ります。CoworkVMServiceやカーネルが保持するレジストリハイブが原因のケースはユーザー権限では解放できず、再起動が確実な最終手段になります。修正版はまだ出ていないため、更新前にCodeタブのセッションを閉じておくといった予防策が、ユーザー側で取れる対策になります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude をもっと見る →