Claude CodeでscoopのGit Bashを使う設定
scoopで入れたGitはbash.exeがProgram Files以外にあり、Claude Codeの自動検出が失敗することがあります。CLAUDE_CODE_GIT_BASH_PATHで直接指定する手順です。
scoopでGitを入れると、Claude CodeがGit Bashを見つけられないことがあります。原因はscoopが実行ファイルを置く場所にあり、CLAUDE_CODE_GIT_BASH_PATHでbash.exeの場所を直接指定すれば解決します。
まだscoopでGitを入れていない場合は、次のコマンドでインストールできます。Gitはscoopのmainバケットに含まれているパッケージで、追加のバケット登録は要りません。
scoop install gitscoopのGit Bashが見つからない理由
CLAUDE_CODE_GIT_BASH_PATHとは、WindowsでClaude CodeがGit Bashの実行ファイル(bash.exe)を探すためのパスを明示する環境変数です。Git Bashをインストール済みでも、Claude Codeが自動で見つけられないときに使います。
この変数が未設定のとき、Claude Codeがbash.exeを探す場所は2か所です。scoopのGitは1番目の場所には置かれず、2番目もPATHに入るのがシムのため、届かないことがあります。
Claude Codeが探す場所とscoopの置き場所
Claude Codeの検出順
- 1番目は
C:\Program Files\GitとC:\Program Files (x86)\Git - 2番目は
PATH上のgitがあるGitインストール先のbin\bash.exe
scoopの既定の置き場所
- 実体は
~\scoop\apps\git\<バージョン>\で、currentがそこを指す PATHに入るのは~\scoop\shims\のラッパー(シム)だけ
この組み合わせでは、2番目の手順でもbash.exeのあるフォルダーに届かない可能性があります。scoopのGitマニフェスト(ScoopInstaller/Mainのgit.json)がbinに挙げる実行ファイルは、sh.exe・git.exe・gitk.exe・git-gui.exe・scalar.exe・git-bash.exeと、gpg関連・pinentry.exeです。bash.exeはシムの対象に入っていません。
2番目の手順には除外もあります。Claude Codeを起動したフォルダー自身、またはその配下でnode_modulesや.venvのような仮想環境フォルダーを含むパスにあるgitは、検出から外れます。プロジェクトが持ち込んだ実行ファイルを誤って使わないための挙動です。
bash.exeの実際の場所を調べる
scoopでインストールしたアプリの実体は、~\scoop\apps\<アプリ名>\current\という場所にあります。currentはディレクトリジャンクションで、常にインストール済みの最新バージョンを指すため、バージョンが上がってもこのパスは変わりません。
インストール先のルート(既定は%USERPROFILE%\scoop)は自分で変えている場合もあります。決め打ちするより、scoop prefixコマンドで実際の場所を調べるほうが確実です。
scoop prefix git出力されたパスの末尾に\bin\bash.exeを足した文字列が、設定に使う値です。既定のインストール先のままなら、次のようになります。
C:\Users\<ユーザー名>\scoop\apps\git\current\bin\bash.exe公式のトラブルシューティングは、Gitの場所をwhere.exe gitで調べる手順を挙げています。scoopでは、このコマンドが返すのはshimsフォルダーのgit.exeです。そこからbin\bash.exeをつなげても、実在するパスになりません。scoop prefix gitはアプリ本体のフォルダーを返すので、こちらを使います。
scoopのGitマニフェストには、もう一つ手がかりがあります。env_setでGIT_INSTALL_ROOTという環境変数にインストール先を入れる定義です。PowerShellで$env:GIT_INSTALL_ROOTを表示すると、scoopが設定した場所を見られます。
scoopのgitパッケージは、git-for-windows/gitが公開している「PortableGit」を取得します。配布形式はPortableGit-<バージョン>-64-bit.7z.exeという自己展開形式の7zです。通常のインストーラー版と同じGitHub releaseに並んでおり、bin\・usr\bin\のフォルダー構成を保ったまま展開されます。そのためbin\bash.exeは、公式インストーラー版のC:\Program Files\Git\bin\bash.exeと同じ相対位置にあります。違うのは親フォルダーだけです。
CLAUDE_CODE_GIT_BASH_PATHを設定ファイルに書く
調べたパスを、settings.jsonファイルのenvキーに書きます。バックスラッシュはJSON内で1つを\\とエスケープする必要があります。
{
"env": {
"CLAUDE_CODE_GIT_BASH_PATH": "C:\\Users\\<ユーザー名>\\scoop\\apps\\git\\current\\bin\\bash.exe"
}
}個人用の~/.claude/settings.jsonに書きます。パスにユーザー名が入るため、プロジェクトの.claude/settings.jsonにコミットして共有する設定には向きません。設定を反映するには、Claude Codeを再起動するのが確実です。
グローバルインストールの場合のパス
scoop install git --global(短縮形-g)でGitを入れた場合、実体は個人用のフォルダーではなく、全ユーザー共通の場所に置かれます。個人インストールとグローバルインストールでは、既定のパスが次のように変わります。
| インストール方法 | 実体のルート(既定) | bash.exeのパス |
|---|---|---|
scoop install git | 実体のルート(既定)%USERPROFILE%\scoop | bash.exeのパス%USERPROFILE%\scoop\apps\git\current\bin\bash.exe |
scoop install git --global | 実体のルート(既定)%ProgramData%\scoop | bash.exeのパス%ProgramData%\scoop\apps\git\current\bin\bash.exe |
どちらのルートも環境変数(%SCOOP% / %SCOOP_GLOBAL%)で変更できるため、この表はあくまで既定値です。迷ったらscoop prefix gitの出力を優先します。
設定したのに効かないときの原因
CLAUDE_CODE_GIT_BASH_PATHが効いているかどうかは、--debug付きで起動すると分かります。パスが無視されている場合、警告がここに出ます。
claude --debug警告を後から探したいときは、--debug-fileが使えます。v2.1.289のclaude --helpには、次のように出ます。
-d, --debug [filter] Enable debug mode with optional category
filtering (e.g., "api,hooks" or
"!1p,!file")
--debug-file <path> Write debug logs to a specific file path
(implicitly enables debug mode)--debug-file <ファイル名>を付けて起動すれば、デバッグモードが有効になり、ログがそのファイルに残ります。起動直後の警告が流れていく端末でも、ファイルを開いて探せます。
公式ドキュメントは、この変数が受け付けるファイル名をbash.exe・sh.exe・bash・shの4つに限っています。よくある失敗は、Git Bashのウィンドウを開くランチャーのgit-bash.exeを指定してしまうことです。
scoopでは、この失敗が起きやすい事情があります。scoopのGitマニフェストはgit-bash.exeもシムに登録するため、shimsフォルダーにはgit-bash.exeが並びます。名前から選んで指定すると、受け付けられない名前に当たります。shimsフォルダーのファイルは指定せず、scoop prefix gitが返すフォルダー配下のbin\bash.exeを使います。
名前が対象外のとき、Claude Codeは変数を無視して自動検出にフォールバックし、--debugで見える警告を出します。パスそのものが存在しない場合も同じ扱いです。
この挙動はv2.1.219(2026年7月24日)で変わりました。それ以前は、ファイル名を調べずそこにあるファイルをそのままシェルとして使い、パスが存在しないときはClaude Codeが起動時に終了していました。今のバージョンでは、名前が合わない・パスが無いどちらの場合も起動は続き、警告だけが出ます。
ファイル名もパスも正しいのにまだ認識されない場合、公式ドキュメントは別の要因を挙げています。AppLockerやグループポリシーのソフトウェア制限、EDRエージェントといった企業のエンドポイントセキュリティ製品の干渉です。社給PCで使っている場合は、claude.exeと、そこから起動されるcmd.exe・bash.exeの許可をIT部門に確認する対象になります。
もう一つ見落としやすいのが、Program Filesに別のGitがすでに入っているケースです。1番目の検出手順はC:\Program Files\Gitの存在を、PATHの状態とは無関係にチェックします。そのためそちらのGitが先に見つかり、scoop側のGit BashはCLAUDE_CODE_GIT_BASH_PATHを設定しない限り使われません。両方のGitを使い分けたい場合は、この変数で明示的にscoop側を指定する必要があります。
gitコマンドが今どちらを指しているか知りたいときは、scoop whichコマンドが使えます。
scoop which git~\scoop\apps\git\current\cmd\git.exeのように、シムが指す実体のパスが返れば、gitコマンド自体はscoop経由です。このパスのcmdをbinに読み替えるとbash.exeの場所になります。ただし、これはgitコマンドの解決先であり、Claude Codeのbash.exe検出とは別の話です。
この設定が要るのはどんな人か
Windows版のClaude Codeは、Git Bashが無くてもPowerShellツールで動きます。この設定が要るのは、bashベースのスクリプトをBashツール経由で実行したい人です。加えて、すでにscoopでGitを管理していて、Git for Windowsの単体インストーラーを別途入れたくない人にも当てはまります。逆に、PowerShellだけで完結する運用なら、この設定自体が不要です。
WSL(Windows Subsystem for Linux)でClaude Codeを使っている場合も、この設定とは無関係です。WSLはLinuxディストリビューション内のbashをそのまま使うため、Windows側のGit BashもCLAUDE_CODE_GIT_BASH_PATHも関与しません。
Git Bashを常用シェルにすると、キー入力の挙動がWindowsの他のターミナルと違うことにも気づきます。たとえばBackspaceでGit Bashだけ単語ごと消えない挙動は、mintty特有の既定によるものです。長いコマンドが途中で切れる問題は約8KBの切り詰めにまとめています。
Git Bashを入れると、アカウントの種類によってPowerShellツールの既定も変わります。claude.aiとConsoleアカウントでは、Git Bash導入後もPowerShellツールが既定で有効なままです。一方、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryのセッションでは既定が逆になります。CLAUDE_CODE_USE_POWERSHELL_TOOL=1を別途設定しない限りPowerShellツールは無効のままで、Bashツールだけで運用することになります。
まとめ
scoopのGitはシム経由でPATHに入るため、Claude Codeの検出がbash.exeに届かないことがあります。その場合はscoop prefix gitの出力に\bin\bash.exeを足した値をCLAUDE_CODE_GIT_BASH_PATHに書けば、Bashツールで使えます。Program Filesに別のGitがあるなら、そちらが先に選ばれるので、この変数での指定が要ります。