Claude CodeがWindowsでstdoutを取得できない原因と対処法

Windows版Claude CodeのBashツールは、.shファイルなどshebang付きスクリプトを実行してもstdoutを返さないことがありました。コマンドの終了コードは0(成功)なのに、出力欄だけが空になる不具合です。原因は~/.bashrcの存在に絡む内部処理で、Anthropicは2026年1月30日のv2.1.27で最初の修正を入れました。2月3日のv2.1.30では、.bashrcのあるWindows環境でBashコマンドが実行できなくなる回帰も直っています。v2.1.30以降のバージョンならこの不具合は解消済みです。ここでは症状の見分け方、修正までの経緯、当時コミュニティが使っていた回避策を、GitHub issueとchangelogから振り返ります。

Windowsで.shスクリプトを実行すると出力が消える症状

症状は明確です。shebang行を持つスクリプトファイルを実行すると、成功はするのにstdoutが空になります。一方でシェルにコマンド文字列を直接渡す実行方法は問題なく出力を返します。終了コード1で出力も空になる場合は別の症状で、切り分けの手順があります。

# スクリプトファイルを作成
cat > /tmp/test.sh << 'EOF'
#!/bin/sh
echo "hello from script"
EOF
chmod +x /tmp/test.sh
 
# 出力が消えるパターン
/tmp/test.sh
sh /tmp/test.sh
bash /tmp/test.sh
 
# 出力が返るパターン
sh -c "echo hello"
bash -c "echo hello"
echo "echo hello" | sh

GitHub issue #18469に報告された検証結果は次の通りです。

この不具合が深刻だったのは、npmがインストールするCLIツールのシムがshebang付きシェルスクリプトそのものだったためです。issueには、Claude Codeからnpm run lintを実行するとツール結果が「(No content)」になり、npm.cmd run lintなら出力が返るという報告があります。ssh host "docker ps"も同じ症状でした。

もう一つ厄介なのは、モデル側に失敗が伝わらない点です。コマンドは成功しているのに出力が空で返るため、モデルは失敗か成功かを判断できません。ある報告者は、この誤認を避けるためにCLAUDE.mdへ「npmはnodeでnpm-cli.jsを直接呼ぶ」と書いて回避していました。

報告者が最初に立てた仮説とAnthropicの初期対応

不具合が報告され始めた直後、報告者の一人は公式changelogを手がかりに仮説を立てました。v2.1.0で入った「BashコマンドとエージェントのCtrl+B統一バックグラウンド化」と、v2.1.2で入った「大きな出力をディスクに保存する方式への変更」が、shebang経由で起動したサブプロセスのstdoutを拾えなくしているのではないか、という仮説です。この段階では裏付けのない、changelogの記述から逆算した推測でした。

Anthropic側は当初、複数のバージョンで試しても再現できないとして、この報告を一度クローズしています。担当者はbash --versionやwinverなど切り分け用の情報を求めました。これに対し別の報告者が「有料ユーザーからの再現報告がある中でクローズするのは筋が違う」と指摘し、日々の作業で回避策を使わざるを得ない状況への不満を表明しています。この過程で、Windows 11の新規インストール環境でも.bashrcを作成した瞬間に症状が再現する、という手順が提示され、原因の絞り込みが大きく進みました。

原因は~/.bashrcの存在とshebang実行の組み合わせ

Claude Codeチームが最終的に特定した原因は、~/.bashrcの存在に関する内部処理の不具合でした。担当者はissue内で次のように説明しています。

we found a repro & hotfixed it (it was in-fact due to some nuances with the presence of ~/.bashrc)

この説明に先立ち、別の報告者がコミュニティ側の検証で細かい切り分けを行っています。同一内容のスクリプトでも、shebang行の有無だけで結果が変わるという報告です。shebangが無いスクリプトは出力を取得できるのに対し、#!/bin/bashを付けた瞬間に取得できなくなります。同じコマンドをGit Bashの端末やPowerShellで直接実行すると正常に動くため、症状はClaude Code内だけで起きていました。

この報告者は、sourceコマンドでスクリプトを読み込んだ場合は出力が返ることも確認しています。sourceは現在のシェルプロセス内でスクリプトを実行するのに対し、直接実行やbash経由の実行はshebangを解釈して子プロセスを生成します。この子プロセス生成の有無が症状の分かれ目だ、というのがコミュニティ側の結論です。Anthropic側が同じ内部メカニズムに言及した発言はissueにありません。

なお、Claude CodeのBashツールがセッション開始時に~/.bashrcを読み込む仕組み自体は正常な挙動です(Claude Codeのシェル起動設定を参照)。今回の不具合についてAnthropicの説明は「~/.bashrcの有無に絡む細かな挙動」にとどまり、内部の仕組みは公表されていません。

影響を受けた範囲

新規インストールのWindows 11で再現手順を示した報告(Claude Code v2.1.25、install.ps1によるネイティブ版)では、CLI、Desktop App(v1.1.1520)、VSCode拡張(v2.1.25)のすべてで症状が出たとされています。.bashrcの中身は空でも、設定が入っていても結果は同じでした。

壊れていたのは「shebang付きファイルを実行してサブプロセスを起動する」経路だけです。sh -cやbash -cで文字列を渡す方法、パイプでシェルに渡す方法、node script.jsのようにスクリプトエンジンを直接呼ぶ方法は、いずれもstdoutを返していました。報告が集まっているのはWindowsネイティブ環境(Git Bash)で、WSL上の報告はissueにありません。issueのコメントでは、macOSでも同様の症状があるとして別のissue(#19663)が参照されています。

修正版が出るまでの回避策(当時の記録)

修正が入るまでの間、コミュニティは複数の回避策を共有していました。今も古いバージョンに固定した環境が残っている場合の参考になります。ただし効果は報告ごとに割れており、1つで直らなければ別の方法に切り替える前提で読んでください。

自作スクリプトをsh -cで包む場合は、次の形になります。

sh -c "$(cat /tmp/test.sh)"

ただし直接実行とは挙動が変わります。スクリプト内で$0や自身のパスを参照していると、結果が違ってきます。

バージョンを固定する

報告者の一人は回避策として2通りを共有していました。1つは/configからstableチャンネルへ切り替えてv2.1.2までダウングレードする方法です。もう1つは.claude/settings.json(または.claude/settings.local.json)にminimumVersionを追記したうえで、v2.1.7を明示的にインストールする方法でした。

# .claude/settings.json に追記
# "autoUpdatesChannel": "stable",
# "minimumVersion": "2.1.7"

# Windowsでv2.1.7を明示的にインストールする場合(PowerShell)
& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 2.1.7

バージョンを指定したインストールは、現行のCLIにも組み込まれています。v2.1.289のclaude install --helpは次のとおりです。

claude install --help

Usage: claude install [options] [target]
 
Install Claude Code native build. Use [target] to specify version (stable,
latest, or specific version)
 
Options:
  --force     Force installation even if already installed
  -h, --help  Display help for command

ここで注意が必要なのはminimumVersionの役割です。マネージド設定ガイドやsettings完全ガイドにある通り、minimumVersionは自動更新やclaude updateがそれより下のバージョンを入れるのを止める「フロア」の指定です。バージョンをそこに固定したり、ダウングレードさせたりする仕組みではありません。minimumVersionだけでは、既に不具合の入ったバージョンを使っている環境がv2.1.7へ戻ることもありません。

古いバージョンを使い続けたい場合は、更新を止める側の設定も要ります。DISABLE_AUTOUPDATERはバックグラウンドの自動更新だけを止め、claude updateとclaude installは動きます。手動の更新も含めて止めるのはDISABLE_UPDATESです。

v2.1.7へ戻しても直らなかったという報告もあります。issueには「Shell outputs still broken for me with 2.1.7」(2026年1月24日)や、v2.1.7でもnpm --versionが動かないという1月29日のコメントがあります。その場合は、次の.bashrcの退避に切り替える方法が案内されていました。

~/.bashrcを一時的にリネームする

原因が.bashrcの存在そのものだったため、ファイルを退避すると症状が消えることも報告されていました。issueでは「Try running mv ~/.bashrc ~/.bashrc_backup」と案内され、~/.claudeを消してから入れ直して直ったという報告もあります。

mv ~/.bashrc ~/.bashrc_backup
# Claude Codeを起動して作業
mv ~/.bashrc_backup ~/.bashrc

修正に至るまでの経緯

issueのコメントとchangelogを日付順に並べると、報告から修正までは次の流れです。混入時期の証言は報告者の手元の比較にとどまり、v2.1.7は正常でv2.1.8から異常という報告が代表的でした。

同じ時期のWindows対応では、Bashツールが別の原因で失敗する不具合がv2.1.55でも直っています。こちらはEINVALエラーが出る問題で、出力が空になる今回の症状とは原因が違います。さらにv2.1.120では、Git Bash自体が無い環境でもPowerShellがシェルツールとして自動で使われるようになりました。npmやpnpmのラッパーだけ出力が空になる未解決の報告は、Git Bashで出力が空になる症状の切り分けで扱っています。

いまのWindowsではどのシェルが使われるか

現行のドキュメントでは、Git for Windowsの導入は任意です。Git Bashを入れた環境では、Bashツールがそれを使います。Claude CodeがGit Bashを見つけられないときは、settings.jsonにパスを指定します。

{
  "env": {
    "CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
  }
}

PowerShellツールは、Git Bashが無いWindowsでは自動で有効になります。Git Bashがある環境でも、claude.aiとConsoleのアカウントなら既定でオンです。Amazon Bedrock・Google Cloud・Microsoft Foundryで使う場合はCLAUDE_CODE_USE_POWERSHELL_TOOL=1で有効にします。PowerShellが主のシェルになっても、Git Bashがあれば、POSIXスクリプト用にBashツールは使えます。

このため、今のWindowsで「シェルスクリプトの出力が返らない」場合は、どのツールが実行したのかを先に見る価値があります。Bashツールなら.bashrcとシェルの起動設定、PowerShellツールならPowerShell側の設定が調べる対象です。

今の環境が対象かを確認する方法

まとめ

Windows版Claude CodeのBashツールには、.bashrcがあるとshebang付きスクリプトのstdoutが消える不具合がありました。修正はv2.1.27、回帰の修正はv2.1.30で入っているので、v2.1.30以降の環境では古い回避策を使う必要はありません。同じ症状が出るなら、バージョンの確認に続けて、実行したのがBashツールかPowerShellツールかを切り分けるのが近道です。なお、macOS・Linux・WSLでの出力凍結には別の環境変数が有効です。