docker-via-wsl

WSL 経由の Docker（Windows）

該当する場合

AI エージェントが Windows ホスト上で動作し、シェルが WSL の外にある場合に該当します。Bash ツールが Git Bash/MSYS（uname -s の結果が MINGW64…/MSYS…）の場合、または PowerShell/cmd を使用している場合です。その環境の docker バイナリは Docker Desktop と通信しますが、デーモンとそのファイルシステムは WSL2 内にあるため、wsl.exe 経由で WSL 内からコマンドを実行する必要があります。

シェルがすでに WSL 内にある場合（uname -s の結果が Linux で、ネイティブパスが /home/<user>/... の場合）、この手順は該当しません。docker を直接実行してください。

問題

Windows では、Docker Desktop のデーモンはWSL2 VM 内で動作します。run、build、exec、pull、push、volume、network、inspect、compose など、すべての docker コマンドを、ネイティブ Linux パスに対してWSL 内から実行してください。Windows シェル（Git Bash/MSYS/PowerShell）からは決して実行しないでください。特に、マップされたネットワーク/SMB ドライブ（Z:、UNC \\host\share）から実行しないでください。

重要な理由

作業ディレクトリ（CWD）がネットワーク共有上にある状態で Windows シェルから Docker を操作すると、Docker Desktop は Windows のバインドパス（例：Z:\proj\config）を VM のパスに変換する必要があります。SMB/UNC ドライブではこの変換が不安定で、パスの一部が重複することがあります（例：…/user/user/proj/config）。その結果、Docker は誤った空のディレクトリをマウントし、存在しないバインド元を空のディレクトリとして自動作成します。コンテナが必要とするファイル（init.sql、設定ファイルなど）がディレクトリとして認識され、could not read from input file: Is a directory が発生します。エディターによる書き込みは共有経由で正しいパスに反映されるため、ホスト側とコンテナ側の表示が気づかないうちに食い違います。

これは Docker のキャッシュの不具合でも、「単一ファイルのバインドマウントは不安定」という問題でもありません（単一ファイルのバインドマウントは WSL からなら正常に動作します）。根本原因は、WSL ではなく Windows/SMB から Docker を操作していることです。

ルール

すべての Docker コマンドを WSL 経由で、ネイティブ Linux パス内から実行してください。

wsl.exe -e bash -lc "cd /home/<user>/<project> && docker compose up -d"
wsl.exe -e bash -lc "docker ps"
wsl.exe -e bash -lc "docker build -t myimg /home/<user>/<project>"

プロジェクトは、Windows のドライブ文字経由ではなく、WSL ディストリビューションがネイティブに認識するLinux ファイルシステム（/home/<user>/...）上に置いてください。

診断と修正

マウントされたパスの確認、ホスト側とコンテナ側の表示の比較、残存するバインドディレクトリのクリーンアップについては、references/diagnosis-and-fix.md を参照してください。