Claude Desktop経由でDockerが落ちる原因と回避策(Windows)

Windows版Claude DesktopのCodeタブでDocker Desktopを起動させると、Dockerが毎回クラッシュする。この症状がGitHubのissue #100901に報告されています(open)。画面にエラーを出すのはDocker側で、ダイアログを見るのは人間だけです。エージェントには docker コマンドがパイプへ接続できないという結果しか見えません。

原因として報告されているのは、Claude Desktopが起動するシェルがMSIXのAppData仮想化の下で動き、AppData配下のAF_UNIXソケットファイルを開けないことです。回避策は、Docker Desktopを explorer.exe 経由で起動することです。

何が起きているのか

issueの報告者は、Windows 11 Enterprise(10.0.26100)でClaude DesktopのMSIX版を使っています。Claude CodeはClaude Desktopに同梱された2.1.293、Docker Desktopは4.89.0、WSLは2.7.13.0です。

症状は次の流れで出ます。

報告者のログに残っていたエラーは次の1行です。

rename C:/Users/<user>/AppData/Local/Docker/run/sailor-ingest.sock C:/Users/<user>/AppData/Local/Docker/run/sailor-ingest.sock.stale: The file cannot be accessed by the system.

これは初回の起動では起きにくい症状です。前回セッションのソケットが残っていて、Dockerがそれを退避しようとしたときに落ちます。報告者によれば、約7週間のあいだにエージェントがDockerを約49回起動し、待ち時間は合計で約4.7時間でした。

原因はAppDataの仮想化とソケットの相性

issueによると、Claude Desktopのシェルと、そこから起動した全プロセスは、パッケージのAppDataファイルシステム仮想化の下で動きます。プロセスの親子は explorer.exe → Claude.exe → claude.exe → シェルです。

この状態で %APPDATA% や %LOCALAPPDATA% 配下のUnixドメインソケット(リパースタグ 0x80000023)を開くと、ERROR_CANT_ACCESS_FILE(1920)で失敗します。報告された範囲は次のとおりです。

• リネーム、削除、fsutil reparsepoint query がすべて失敗する(管理者権限でも同じ)
• %LOCALAPPDATA%\Temp、プロファイル直下、C:\ では起きない
• explorer.exe や Win32_Process.Create 経由で起動したパッケージ外のプロセスからは、同じファイルが普通に開ける

WPR(Windows Performance Recorder)のトレースでは、AppData\Roaming\sock-test\mine.sock へのopenが、実際には AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\sock-test\mine.sock に対して発行されていました。つまりファイルの実体はパッケージ専用の場所にあります。

もう1つ気になるのは、エージェントのシェル自体にはパッケージIDが無い点です。GetCurrentPackageFullName は APPMODEL_ERROR_NO_PACKAGE を返しますが、AppDataへのアクセスは仮想化されたままだと報告されています。

Dockerが作るフォルダーも見えなくなる

仮想化の影響はソケットだけではありません。DockerがAppDataに新しく作るトップレベルのフォルダー(例: docker-secrets-engine)も、%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local の中に入り、アプリの外からは見えなくなります。

同じ現象はDocker以外でも出ます。別のissue(#94254)では、Claude Codeのセッションが %LOCALAPPDATA% に書いたスクリプトが、タスクスケジューラなどパッケージ外のプロセスから見えなかったと報告されています。仮想化は書き込みだけに効くため、既存のファイルの読み取りは通ります。そのせいで気づきにくい不具合です。

自分の環境で同じ状態か確かめる

issueに載っている再現手順はPowerShell 7で動きます。Claude DesktopのCodeタブから実行し、続けて通常のターミナルでも同じ確認をします。

New-Item -ItemType Directory -Force "$env:APPDATA\sock-test" | Out-Null
$s = [System.Net.Sockets.Socket]::new(
  [System.Net.Sockets.AddressFamily]::Unix,
  [System.Net.Sockets.SocketType]::Stream,
  [System.Net.Sockets.ProtocolType]::Unspecified)
$s.Bind([System.Net.Sockets.UnixDomainSocketEndPoint]::new(
  "$env:APPDATA\sock-test\a.sock")); [Environment]::Exit(0)

ソケットを作ったら、同じセッションの中で次を実行します。

fsutil reparsepoint query "$env:APPDATA\sock-test\a.sock"

Codeタブからは Error 1920: The file cannot be accessed by the system. が返り、通常のターミナルでは成功するなら、報告と同じ状態です。

後片付けにも注意があります。ファイルの実体はパッケージ側にあるため、アプリの中からは消せません。通常のターミナルから %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\sock-test を削除します。

回避策: Docker Desktopをexplorer.exe経由で起動する

issueの報告者が挙げている回避策は、Docker Desktopを explorer.exe から起動することです。explorer.exe で起動したプロセスはパッケージの外に出るため、ソケットの扱いが通常のターミナルと同じになります。

explorer.exe "C:\Program Files\Docker\Docker\Docker Desktop.exe"

エージェントに任せる場合は、CLAUDE.mdに起動方法を書いておく手があります。

## Docker Desktop(Windows)
- Docker Desktop が停止しているときは `Docker Desktop.exe` を直接起動しない。
- 次のコマンドで起動し、`docker info` が通るまで待つ。
  `explorer.exe "C:\Program Files\Docker\Docker\Docker Desktop.exe"`
- 起動に失敗しても、プロセスの強制終了やフォルダーのリネームは試さずに報告する。

この書き方はissueの回避策をCLAUDE.mdの規約にしたものです。公式に推奨された手順ではありません。最後の1行は、エージェントが再試行のたびにプロセスをkillしフォルダーを動かす挙動(issueの記述)を止めるための歯止めです。

Dockerが起動したあとの docker コマンドは、エージェントのシェルからそのまま使えるかどうか、issueには書かれていません。Dockerをテストに使う手順は、Testcontainersのテストをsandbox越しに動かす手順も参考になります。

起動後に確かめること

explorer.exe 経由で起動したあとは、Dockerが立ち上がりきったかを docker info で確かめます。エンジンが応答するまでには時間がかかるため、直後のコマンドが失敗しても、すぐ再起動せず少し待ちます。待っても繋がらないときは、通常のターミナルから同じコマンドを実行して、症状がエージェント側だけに出ているかを見ます。通常のターミナルでも繋がらないなら、Docker自体の問題です。この記事の原因とは別に切り分けます。

古い報告との関係

issue本文は、同じ根を持つ過去の報告として #73543と #76383を挙げています。どちらも修正されないままinactiveとしてclosedになっています。

#76383の報告には、#100901と食い違う点があります。#76383は %LOCALAPPDATA%\Temp 配下のソケットでも消せなくなったと書いていますが、#100901はTemp配下では起きないとしています。報告されたClaude Codeのバージョンも環境も違うため、どちらが一般的かは判断できません。Tempに逃がせば解決すると決めつけず、上の再現手順で自分の環境の動きを確かめるのが確実です。

#76383ではDocker Sandboxesの sandboxd デーモンも被害を受けています。ソケットのパスが「汚染」され、以後は起動できなくなったという内容です。Docker関連の症状が別の形で出る可能性があります。

MSIX側の仕様と、直す側の選択肢

AppDataへの書き込みのリダイレクトはMSIXの仕様です。Microsoftのドキュメントによると、パッケージの仮想化されたAppDataは、書いたアプリにしか見えず、アンインストール時に消えます。

パッケージ側がこの動作を止める手段も用意されています。マニフェストで desktop6:FileSystemWriteVirtualization を disabled にすると、AppDataへの書き込みは実際の場所に行き、パッケージ外のプロセスからも見えます。Windows 11以降は、特定のフォルダーだけを仮想化から外す virtualization:ExcludedDirectories も使えます。

issueの報告者の提案は2つです。

• エージェントのシェルとツールのプロセスを、アプリのコンテナの外で起動する(PROC_THREAD_ATTRIBUTE_DESKTOP_APP_POLICY と PROCESS_CREATION_DESKTOP_APP_BREAKAWAY_ENABLE_PROCESS_TREE を使う)
• パッケージ側でAppDataの書き込み仮想化を無効にする

コメント欄には、OpenAI Codexのissueで同じAF_UNIXのerror 1920を別のPCで再現した、という報告があります。ただしClaude DesktopはそのPCでは試されておらず、提案されたマニフェスト変更も、作り直したMSIXでの検証は済んでいません。修正の見込みはまだ示されていません。

切り分けの目安

この不具合は、MSIXパッケージとして動くClaude Desktopに紐づく報告です。MSIX版かどうかや、同じパッケージで起きる別の不具合は、0x80073CF9とpriconfig.xmlや非ページプールが増え続けるときの記事で扱っています。Windowsでバックグラウンドの claude.exe が溜まる問題は別の記事にまとめています。

まとめ

Docker Desktopが落ちる直接の理由は、Dockerが前回のソケットを退避できないことです。その背後に、Claude DesktopのMSIXパッケージがAppDataを仮想化し、ソケットファイルの操作がerror 1920で失敗する問題があると報告されています。

今日できる対処は、Docker Desktopを explorer.exe から起動することです。エージェントに任せるなら、起動方法をCLAUDE.mdに書き、失敗時の強制終了を禁じておくと、時間の浪費を避けられます。パッケージ側の修正は、issueがopenのまま進行中です。