Claude CodeでGit Bashが検出されない——CLAUDE_CODE_GIT_BASH_PATHを設定しても直らない原因を公式ドキュメントで潰す
WindowsでClaude Codeが「requires git-bash」を出し続ける原因を、ファイル名の落とし穴・v2.1.219の挙動差・EDRによるブロックに分けて解説。設定例と診断コマンドつき。
エンジニアのゆとです。
WindowsでClaude Codeを起動するとClaude Code on Windows requires either Git for Windows (for bash) or PowerShellというエラーが出て、Git Bashは確かにインストール済みなのに検出されない——という相談をちらほら見かける。CLAUDE_CODE_GIT_BASH_PATHをsettings.jsonに設定すれば直るはずなのに直らない、というパターンが特に厄介で、GitHubのIssueにも同じ内容の報告が何本も重複して立っている。
自分はmacOS + WSLの組み合わせで動かしているのでこのエラー自体は踏んだことがないんだけど、クライアント先のWindows専用端末でセットアップを手伝ったときに、まさにこれで小一時間溶かした。原因はドキュメントを読めば一発で分かる話だったので、この記事に整理しておく。
結論 — 大体この4パターンのどれか
bash.exeのパスは合っているはずなのに検出されない、という場合の原因は次の4つに収束する。
| 症状 | 原因 |
|---|---|
パスは正しいのにCLAUDE_CODE_GIT_BASH_PATHが無視される | ファイル名がbash.exe/sh.exe/bash/shのいずれでもない（git-bash.exeを指定している等） |
Program Files配下のGitを指定すると失敗する | パスに含まれる半角スペースの扱いに起因する既知の不具合 |
| Claude Code CLIでは直るのにVS Code拡張機能だけ直らない | CLIと拡張機能で検出ロジックが別実装になっている |
| 設定もファイル名も正しいのに毎回このエラーで止まる | 社内のEDR・AppLockerがbash.exeやcmd.exeの起動をブロックしている |
まずは自分がどのパターンかを診断コマンドで切り分ける。
そもそもGit for Windowsは必須ではない
前提として、Claude CodeはWindowsでGit Bashが無くても動く。公式ドキュメントによれば、Git Bashが見つからない場合はPowerShellツールにフォールバックする設計になっている。つまりこのエラーが出る場合、「Git BashもPowerShellも両方見つからなかった」ことを意味する。
PowerShellがPATHに無い場合は、デフォルトの場所（C:\Windows\System32\WindowsPowerShell\v1.0\）をPATHに追加するか、pwshコマンドが使えるPowerShell 7を入れれば解決する。Bashスクリプトやbash系のツールを使う予定がないなら、Git for Windowsを入れずにPowerShellだけで運用する選択肢も普通にある。
一方で、既存のBashスクリプトを使う開発フローに乗っているなら、Git Bashを入れたほうが結局は楽だ。ここから先は「Git Bashを使いたいのに検出されない」場合の原因を順番に見ていく。
まず診断する — where.exe gitでパスを確定させる
思い込みでC:\Program Files\Git\bin\bash.exeを決め打ちする前に、実際のインストール場所をPowerShellで確認する。
where.exe git表示されたgit.exeのパスのbin\git.exe部分をbin\bash.exeに読み替えたものが、設定すべき正しいパスになる。Git for Windowsのインストーラーをカスタム設定で使った場合や、Scoop・Chocolatey経由でインストールした場合はデフォルトのC:\Program Files\Git\とは違う場所に入っていることがあるので、ここを飛ばして決め打ちするのが事故の元だ。
パスが確定したら、bash.exeファイルが実在してちゃんと動くかも確認しておく。
Test-Path "C:\Program Files\Git\bin\bash.exe"
& "C:\Program Files\Git\bin\bash.exe" --versionここまででTrueとGNU bash, version ...が返ってくるなら、Git Bash自体は正常に動いている。それでもClaude Codeが検出しないなら、原因はここから先の4パターンのどれかだ。
原因1 — ファイル名がbash.exeではない
一番見落としやすいのがこれ。Claude CodeがCLAUDE_CODE_GIT_BASH_PATHとして受け付けるファイル名はbash.exe・sh.exe・bash・shの4つだけで、それ以外の名前——たとえばGit for Windowsに同梱されている起動用ランチャーのgit-bash.exe——を指定すると、値が設定されていないものとして扱われ、自動検出にフォールバックする。
デスクトップのショートカットや検索結果でよく出てくるのはgit-bash.exeの方なので、「Git Bashのパス」と聞いて素直にそちらを指定してしまう人が多い。正しくは同じbinフォルダの中にあるbash.exeを指定する。
{
"env": {
"CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
}
}存在しないパスを指定した場合も同じ「未設定扱い」のフォールバックになる。どちらのケースも--debugフラグを付けて起動すると警告ログが出るので、パス自体は合っているはずなのに直らないときはまずここで確認するのが早い。
claude --debug
原因2 — バージョンによって挙動が違う
もう1つ見落としやすいのが、Claude Codeのバージョンによって、間違ったパスを指定したときの挙動そのものが変わっている点だ。
v2.1.219より前のバージョンでは、指定されたパスにファイルさえ存在すれば、ファイル名を確認せずにそのままシェルとして使おうとしていた。存在しないパスを指定した場合はその場でエラー終了し、Claude Code was unable to find CLAUDE_CODE_GIT_BASH_PATH pathという、原因1で説明したフォールバックとは別の停止型のエラーメッセージが出ていた。
v2.1.219以降は、ファイル名のチェックが入るようになり、間違ったファイル名を指定した場合は静かに自動検出へフォールバックするように変わっている。つまり同じ「設定ミス」でも、古いバージョンでは派手に落ちて気づきやすく、新しいバージョンでは黙って別の挙動になるため逆に気づきにくい、という逆転が起きている。まずclaude -vで自分のバージョンを確認し、原因1のファイル名チェックと合わせて疑うのが確実だ。
claude -v原因3 — VS Code拡張機能はCLIと別問題として検出する
Claude Code CLIは直るのに、VS Code拡張機能（Claude Code for VS Code）だけ同じエラーを出し続ける場合は、原因がCLIとは別の場所にある。拡張機能とCLIは検出ロジックが別実装になっていて、CLAUDE_CODE_GIT_BASH_PATHを正しく設定してもVS Code側だけ古い値をキャッシュしていたり、拡張機能の初期化タイミングの問題で環境変数を正しく読めていないケースが実際に報告されている。
この場合に効くことが多いのは、VS Codeを一度完全に終了してから開き直すこと、それでも直らなければ拡張機能を一度アンインストールして入れ直すことだ。根本原因が拡張機能側のバグである可能性もあるので、直らない場合はCLI単体（ターミナルからclaudeを直接起動）で運用しつつ、拡張機能側のアップデートを待つという判断も現実的な選択肢になる。
原因4 — EDR・AppLockerが実行をブロックしている
ファイル名もバージョンも問題ないのに直らない場合、最後に疑うべきは会社支給端末のセキュリティソフトだ。AppLockerやグループポリシーのソフトウェア制限ポリシー、あるいはEDR（Endpoint Detection and Response）エージェントが、Claude Codeが起動しようとするbash.exeや、それを呼び出すcmd.exeをブロックしていることがある。
個人の端末ならbash.exeを手動で許可リストに追加すれば済むが、会社支給の管理端末では自分では変更できないことが多い。この場合は情報システム部門に、claude.exe本体と、そこから起動されるcmd.exe・bash.exeをエンドポイント保護のポリシーに許可リストとして追加してもらう必要がある。「Git Bashは単体では起動するのにClaude Code経由だと落ちる」という切り分けができていると、依頼がスムーズに通りやすい。
おまけ — 32bit版PowerShellから起動していないか
直接のCLAUDE_CODE_GIT_BASH_PATHの話ではないけど、同じ「Git for WindowsもPowerShellも見つからない」エラーで別の原因に当たるケースとして触れておく。WindowsのスタートメニューにはWindows PowerShellとWindows PowerShell (x86)の2つのエントリがあり、後者は64bit環境であっても32bitプロセスとして起動する。Claude Codeは32bit版Windowsをサポートしていないため、x86版のPowerShellから実行するとGit BashもPowerShellも「見つからない」扱いになり、同じエラーメッセージが出る。
自分が64bit環境かどうかは、エラーが出たのと同じウィンドウで次を実行すれば確認できる。
[Environment]::Is64BitOperatingSystemTrueが返るなら64bit環境なので問題ない。ウィンドウを閉じて、x86の付いていないWindows PowerShellから開き直せば解決する。Falseが返る場合は本当に32bit版Windowsを使っている状態で、これはOSの64bit版への乗り換えが必要になる。
Git Bashを諦めてPowerShellだけで運用するという選択肢
ここまで4パターン+おまけの原因を挙げてきたけど、正直なところ「Bashスクリプトを直接叩く必要がない」という人には、Git Bashの検出トラブルに時間を使うよりPowerShellだけで運用してしまうほうが早い場合もある。Claude Code自体はGit Bashが無くてもPowerShellツールで動作するので、.claude/settings.jsonにGit Bash関連の設定を一切書かず、素のPowerShell環境として使う手もある。チーム開発でCLAUDE.mdにBash前提のコマンドを書いている場合は別だけど、個人利用ならこの割り切りも十分にありだ。
Windows上でのインストール方式そのもの（WSL2・Git Bash・PowerShell）の使い分けに迷っている場合は、3方式を比較した別記事を参考にしてほしい。
Git Bash云々の前に、そもそもclaudeコマンド自体が見つからない・PATHが通っていないという場合は、こちらの記事で切り分けられる。
FAQ
環境変数はユーザーレベルとシステムレベルのどちらに設定すべき？
CLAUDE_CODE_GIT_BASH_PATHはWindowsの環境変数として設定することもできるが、確実なのは%USERPROFILE%\.claude\settings.json（プロジェクト単位なら.claude/settings.json）のenvキーに書く方法だ。環境変数として設定した場合、反映にはターミナルの再起動、場合によってはサインインし直しが必要になることがある。設定ファイルへの記載なら新しいセッション起動時に確実に読み込まれる。
会社のPCでは管理者権限がなくてEDRの許可リストを自分で変更できない
その場合は、Bashを使わない前提でPowerShellツールに完全に寄せるほうが早い。どうしてもBash実行環境が必要な作業であれば、WSL2を経由する方法もあるので、情シスにWSL2の利用可否を確認するのも選択肢になる。
git-bash.exeとbash.exeは何が違う
git-bash.exeはGUIのターミナルウィンドウを開くためのランチャーで、内部でbash.exeを呼び出している。Claude Codeがシェルとして直接実行できるのはbash.exeの方で、ランチャーであるgit-bash.exeを経由すると二重にウィンドウが開こうとして、コマンド実行の受け渡しがうまくいかない。設定に使うのは必ずbinフォルダ直下のbash.exeにする。
まとめ
CLAUDE_CODE_GIT_BASH_PATHを設定してもGit Bashが検出されない場合、原因は「ファイル名がbash.exeではない」「バージョンによる挙動差」「VS Code拡張機能特有の別実装」「EDR・AppLockerのブロック」のどれかにほぼ収束する。where.exe gitで正しいパスを確定させ、claude --debugで警告ログを確認する——この2つを先にやれば、大半のケースはどのパターンか切り分けられる。
