Claude CodeのGit Bashで出力が空になる — npm・pnpm・dockerの切り分け

WindowsのGit Bashでnpm --versionやdocker psを実行させると、Bashツールの結果が「(No content)」になることがあります。エラーは出ません。終了コードも成功に見えます。出力だけが返りません。この症状はclaude-codeのissue #18748で報告されており、issueはopenのままです。ここでは、症状の見分け方、報告されている原因の仮説、手元で試せる回避策を並べます。

出力が空になるのはどんなコマンドか

issueの報告によると、空になるのは「別プロセスとしてシェルスクリプトのファイルを実行する」経路です。Windowsではnpm、pnpm、dockerなどが、拡張子のないシェルスクリプトをラッパーとして持っています。Git Bashでnpmと打つと、まずこのスクリプトが呼ばれます。

報告者がまとめた結果は次のとおりです。

分かれ目は、スクリプトを「ファイルとして実行するか」「いまのシェルの中で読み込むか」です。.exeや.cmdはWindowsのネイティブ実行ファイルなので、この表では正常側に入ります。

issueには、azコマンドでも同じ症状が出るというコメントがあります。

手元の環境で切り分ける手順

自分の環境が該当するかは、issueの再現手順をそのまま使えば数分で確かめられます。まずテスト用のスクリプトを作ります。

printf '#!/bin/sh\necho "hello world"\n' > /tmp/test.sh
chmod +x /tmp/test.sh

次に、Claude Codeに次の4つを1回ずつ別々に実行させます。まとめて1回で流すと、どの方法が空になったのか分かりません。

/tmp/test.sh
bash /tmp/test.sh
sh -c 'echo "hello world"'
. /tmp/test.sh

issueの報告では、最初の2つが「(No content)」、sh -cと.(source)はhello worldを返しています。同じ結果が出れば、このissueの症状に当たります。sh -cも空になる場合は、スクリプト経由かどうかの問題ではなく、シェルそのものの出力が取れていません。その場合は、次節の3つ目の報告のほうが近い状況です。

原因について出ている仮説

Anthropicによる原因の説明は、issueにはありません。コメントで出ている分析は、報告者やコミュニティによる仮説です。仮説どうしも一致していません。

1つ目は、issueの本文にある推測です。Bashツールがサブプロセスを起動して標準出力を拾うとき、スクリプトファイルの実行だけがうまく拾えない、という見立てです。本文自体が「appears to be」と断定を避けています。

2つ目は、2026年1月28日のコメントです。Node.jsのspawn()でbashを呼ぶ場合、bash -c "echo hello"は出力が取れ、bash script.shは取れない、という対応表を示しています。bashがスクリプトを別プロセスとして実行するとき、標準出力のファイルディスクリプタがMINGW64上で引き継がれない、というのがこのコメントの説明です。sourceが効くのは、同じプロセス内で実行されるからだとしています。

3つ目は、2月18日のコメントです。Git for Windowsを2.34.1から2.53.0に上げたところ、git、docker、npm、nodeなどWindowsネイティブの実行ファイルは出力が取れるようになったと報告しています。一方で、echoやpwdといったbashの組み込みコマンドと、lsやcatのようなMSYS2のユーティリティは、依然として出力が失われるとしています。つまり、この環境で症状の中心は「スクリプトのラッパー」から「MSYS2側のコマンド全般」へ移っています。

この3つは同じ症状の別の側面を見ている可能性がありますが、同一の原因だと示す材料はありません。自分の環境がどれに近いかは、前節のテストで切り分けられます。sh -c 'echo ...'まで空になるなら、3つ目に近い状況です。

報告されたバージョンと環境のばらつき

コメントを時系列で見ると、バージョンごとの証言は食い違っています。

特定のバージョンより新しいか古いかでは線を引けないことが分かります。Git for Windowsのバージョン、~/.bashrcの有無、Windowsのエディションなど、環境側の差も効いているようです。バージョンを固定する対処は、1人の環境では効いても、別の環境では効かなかった例が同じissueの中にあります。

なお、#19663はコメントの時点で重複先として挙げられたissueで、題名はmacOSでBashツールが出力を返さないという報告です。同じissueと見てよいかは、このコメントだけでは決められません。

回避策をリスクの小さい順に試す

issueに出ている対処は、効き方と副作用が違います。

.cmdと.exeを明示する

もっとも単純で、副作用が少ない方法です。npm.cmd、pnpm.cmd、docker.exeのように拡張子を付けます。issueの表でも、この呼び方は出力が返るとされています。

npm.cmd --version
pnpm.cmd --version
docker.exe version

欠点は、人が書くコマンドや既存のスクリプトまで書き換える必要があることです。ラッパー任せのnpm run buildの内側で別のスクリプトを呼ぶ場合、外側だけ直しても内側は直りません。

CLAUDE.mdで呼び方を固定する

Claudeが毎回.cmd付きで呼ぶよう、規約を書いておく方法です。issueのコメントにも、同趣旨の記述をCLAUDE.mdに入れている例があります。次のような書き方が考えられます。

## Windows(Git Bash)でのコマンド実行
- npm・pnpm・docker は `npm.cmd`・`pnpm.cmd`・`docker.exe` で呼ぶ
- シェルスクリプトは `bash script.sh` でなく `. ./script.sh` で読み込む
- 出力が空のときは成功とみなさない。`.cmd` / `.exe` 付きで再実行する

3行目が重要です。あるコメントは、この不具合の怖さを「Claudeが(No content)を成功だと思い込むこと」と指摘しています。ビルドやテストが実は動いていないのに、先へ進んでしまうためです。出力が空のときの扱いを明文化しておけば、少なくとも見逃しは減ります。

source読み込みへの置き換えは、スクリプトの書き方に影響します。別のコメントは、BASH_SOURCEを使うスクリプトでは調整が要ったと書いています。

BASH_ENVで関数に置き換える

最初に出た回避策は、BASH_ENVで読み込むスクリプトの中に、docker() { docker.exe "$@"; }のような関数を定義する方法です。関数はいまのシェルの中で動くので、ラッパーのスクリプトを別プロセスで起動しません。settings.jsonには次のように書きます。

{
  "env": {
    "BASH_ENV": "C:/Users/YOUR_USERNAME/.claude/shell-fixes/mingw64-workarounds.sh"
  }
}

後続のコメントでは、npmのグローバルディレクトリなどを走査して関数を自動生成する版が共有されました。ただし副作用の報告もあります。

• 別の報告者は、関数に置き換えるとc/Program could not be foundのようなエラーが出るコマンドがあると書いています
• ある参加者は、置き換えが効くのは一部のコマンドだけだと述べ、フックが(No content)で失敗していたため使うのをやめています

つまり、常用する前提では危うい方法です。試す場合は、置き換え対象を実際に空になったコマンドだけに絞るほうが安全です。

PowerShellツールかWSLに移る

Bashツールを経由しない道もあります。公式ドキュメントによると、PowerShellツールはコマンドをGit Bash経由でなくPowerShellで直接実行します。Git Bashを入れたWindowsでは、claude.aiとConsoleのアカウントなら既定でオンです。Amazon Bedrock、Google Cloud、Microsoft Foundryで使う場合は、CLAUDE_CODE_USE_POWERSHELL_TOOL=1で有効にします。PowerShellが主のシェルになってもBashツールは残り、POSIXスクリプトに使えます。

$env:CLAUDE_CODE_USE_POWERSHELL_TOOL = "1"
claude

issueのコメントには、PowerShellツールで症状が消えたという検証は出ていません。Git Bashを経由しない実行経路なので、この症状の外に出られる可能性はあります。試すときは、先ほどのテストの代わりにnpm --version相当を実行させて確かめます。

もう1つの移行先がWSLです。issueの参加者の1人は、WSL上でClaude Codeを動かす構成に切り替え、安定して使えていると書いています。Dockerを使う場合はDocker DesktopのWSL連携を有効にする必要があります。ただし、WSLの場合も別の出力欠落を報告するコメントがあり、環境によっては解決しません。

同じ「出力が消える」でも解決済みの不具合とは別物

Windowsで.shの出力が消える不具合には、すでに修正済みのものがあります。~/.bashrcの存在に絡む問題で、v2.1.27とv2.1.30で修正されました。経緯はClaude CodeがWindowsでstdoutを取得できない原因と対処法にまとめています。

見分けるポイントは3つです。

• 解決済みのissueはcloseされ、バージョンが特定されている。今回のissueはopenで、修正バージョンが特定されていない
• 解決済みのほうは.bashrcの作成で再現した。今回の報告は、npmやdockerのラッパーが主な題材になっている
• v2.1.30以降でも出る場合は、解決済みの不具合では説明がつかない

出力の欠落が別の形で現れる例として、コマンドそのものが長すぎて切れる約8KBの問題があります。こちらはコマンドの入力側の問題で、出力が空になる今回の症状とは向きが逆です。

Git Bashの場所をうまく認識できていない可能性もあります。CLAUDE_CODE_GIT_BASH_PATHにbash.exeのパスを指定する設定は、scoopで入れたGit Bashを使う設定で扱っています。パスの問題なら、出力が空になるのでなくシェルが起動しないことが多く、症状は別です。

試す順番と、見落とさないための確認

この問題は、出力が空になるだけで失敗に見えない点が厄介です。実作業で意識しておくと損が少ないのは次の点です。

1. 初めて使うコマンドや、ビルド・テストの実行結果が空のときは、成功と判断せずに終了コードや.cmd付きの再実行で確かめる
2. 症状が出る環境では、npm・pnpm・dockerを.cmdと.exe付きに統一する
3. 回避スクリプトは、効果が出たコマンドだけに限定する
4. Git for Windowsを更新して様子を見る。ただし、更新しても改善しなかった報告もあるので、それだけに頼らない

Windowsのセットアップ全体を見直したい場合は、Claude CodeのWindowsインストールでネイティブとWSLを選ぶ基準が出発点になります。

まとめ

WindowsのGit Bashで出力が空になる症状は、シェルスクリプトを別プロセスで実行するときに出るという報告です。.cmdや.exeを付ける、sourceで読み込む、sh -cに直接渡すと出力は返ります。原因はAnthropicから示されておらず、コメントの仮説も一致していません。issueはopenで、バージョンや環境によって再現の有無も割れています。当面は、.cmd付きの呼び出しと、出力が空のときに成功と見なさない規約をCLAUDE.mdに置くのが、副作用の少ない備えです。