Claude CodeがWindowsでstdoutを取得できない原因と対処法
WindowsのBashツールで.shスクリプトを実行するとstdoutが消える不具合がありました。原因・影響範囲・修正済みバージョン・回避策を一次ソースでまとめます。
Windows版Claude CodeのBashツールは、.shファイルなどshebang付きスクリプトを実行してもstdoutを返さないことがありました。コマンドの終了コードは0(成功)なのに、出力欄だけが空になる不具合です。原因は~/.bashrcの存在に絡む内部処理で、Anthropicは2026年1月末のv2.1.27で最初の修正を入れ、環境によって再発していた分をv2.1.30で修正しました。v2.1.30以降のバージョンならこの不具合は解消済みです。ここでは症状の見分け方、修正に至るまでの経緯、当時コミュニティが使っていた回避策を一次ソースのGitHub issueから振り返ります。
Windowsで.shスクリプトを実行すると出力が消える症状
症状は明確です。shebang行を持つスクリプトファイルを実行すると、成功はするのにstdoutが空になります。一方でシェルにコマンド文字列を直接渡す実行方法は問題なく出力を返します。
# スクリプトファイルを作成
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" | shGitHub issue #18469に報告された検証結果は次の通りです。
| 実行方法 | stdout取得 |
|---|---|
sh -c "echo hello" | stdout取得取得できる |
bash -c "echo hello" | stdout取得取得できる |
echo "cmd" | sh | stdout取得取得できる |
node /path/to/script.js | stdout取得取得できる |
/path/to/script.sh | stdout取得取得できない |
sh /path/to/script.sh | stdout取得取得できない |
bash /path/to/script.sh | stdout取得取得できない |
この不具合が深刻だったのは、npmがインストールするCLIツールのシムがshebang付きシェルスクリプトそのものだったためです。npm経由で入れたprettier・eslintなどのコマンドをClaude Codeから実行すると、コマンド自体は成功するのに結果が一切返らない状態になっていました。ssh経由でdocker psをリモート実行する運用でも同じ症状が報告されており、CI的な使い方をしているチームほど気づきにくい不具合だったといえます。
コミュニティが最初に立てた仮説とAnthropicの初期対応
不具合が報告され始めた直後、報告者の一人spragginsdesigns氏は公式changelogを手がかりに仮説を立てました。v2.1.0で導入された「BashコマンドとエージェントのCtrl+B統一バックグラウンド化」と、v2.1.2で導入された「大きな出力をディスクに保存する方式への変更」が、shebang経由で起動したサブプロセスのstdoutを正しく拾えなくしているのではないか、という仮説です。この段階では確証はなく、あくまでchangelogの記述から逆算した推測でした。
Anthropic側は当初この報告を「再現できない」として一度クローズしています。担当のkm-anthropic氏はbash --versionやwinverなど切り分け用の情報提供を求めました。これに対しevanwon氏は「有料ユーザーからの再現報告がある中でクローズするのは筋が違う」と指摘し、日々の作業でこの不具合の回避策を使わざるを得ない状況への不満を表明しています。この過程でamdcq氏が「Windows 11の新規インストール環境でも、.bashrcを作成した瞬間に症状が再現する」という手順を提示し、原因の絞り込みが大きく進みました。
原因は~/.bashrcの存在とshebang実行の組み合わせ
Claude Codeチームが最終的に特定した原因は、~/.bashrcの存在に関する内部処理の不具合でした。Claude Codeチームのkm-anthropic氏はissue内で次のように説明しています。
we found a repro & hotfixed it (it was in-fact due to some nuances with the presence of
~/.bashrc)
この公式説明に先立ち、報告者Erodenn氏はコミュニティ側の検証でより細かい切り分けを行っています。同一内容のスクリプトでも、shebang行の有無だけで結果が変わることを確認したという報告です。shebangが無いスクリプトは出力を取得できるのに対し、#!/bin/bashを付けた瞬間に取得できなくなる、という再現手順が示されました。Erodenn氏はさらに、sourceコマンドでスクリプトを読み込んだ場合は出力が返ることも確認しています。sourceは現在のシェルプロセス内でスクリプトを実行するのに対し、直接実行やbash経由の実行はshebangを解釈して子プロセスを生成します。この子プロセス生成の有無が症状の分かれ目になっていた、というのがコミュニティ側の結論です。この検証はコミュニティによるもので、Anthropic側が同じ内部メカニズムを認めた発言は見当たりません。
なお、Claude CodeのBashツールがセッション開始時に~/.bashrcを読み込む仕組み自体は正常な挙動です(Claude Codeのシェル起動設定を参照)。今回の不具合はその読み込み処理とは別に、.bashrcというファイルが存在するかどうかがshebang経由のサブプロセス実行時のstdout取得経路に影響していた、という内部的な相互作用でした。
影響を受けた範囲
amdcq氏の検証(v2.1.25時点、Windows 11新規インストール環境)によると、この不具合はWindows上のClaude Codeが提供する複数の利用形態すべてに及んでいました。
| 利用形態 | 影響(amdcq氏の検証時点) |
|---|---|
| CLI(Windowsネイティブ) | 影響(amdcq氏の検証時点)影響あり |
| Desktop App | 影響(amdcq氏の検証時点)影響あり |
| VSCode拡張 | 影響(amdcq氏の検証時点)影響あり |
一方で、影響を受けなかった実行方法もはっきりしています。sh -c や bash -c でコマンド文字列を直接渡す方法、パイプ経由でシェルに渡す方法、node script.js のようにスクリプトエンジンを直接呼ぶ方法は、いずれも問題なくstdoutを返していました。壊れていたのは「shebang付きファイルを実行してサブプロセスを起動する」経路だけです。WSL上のClaude Codeについてはissueスレッド内に言及が見当たらず、影響の有無は確認できません。
修正版が出るまでの回避策(当時の記録)
修正が入るまでの間、コミュニティは複数の回避策を共有していました。今も古いバージョンに固定した環境が残っている場合の参考になります。
実行ファイルの拡張子を明示する
Windowsではnpmが本体の.cmdファイルとシェルシムの2つを持つケースが多く、拡張子を明示すると本体側が呼ばれて症状を回避できました。
# シムが呼ばれて出力が消える
npm run lint
# 本体を明示すると出力が返る
npm.cmd run lint
ssh.exe user@host "docker ps"ただしこの回避策はnpm.cmdのように拡張子違いの実行ファイルが別途存在するコマンドに限られます。自作の.shスクリプトには使えません。
バージョンを固定する
amdcq氏は回避策として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ここで注意が必要なのはminimumVersionの役割です。マネージド設定ガイドやsettings完全ガイドにある通り、minimumVersionは自動更新やclaude updateがそれより下のバージョンを入れるのを止める「フロア」の指定であり、バージョンをそこに固定したりダウングレードさせたりする仕組みではありません。自動更新自体も止まらないため、amdcq氏の投稿にあるminimumVersion単独の設定では、既に不具合の入ったバージョンを使っている場合にv2.1.7へは戻りません。自動更新そのものを止めたい場合はDISABLE_AUTOUPDATERとの併用が必要です。
スクリプトを直接実行せずsh -cでラップする
自作スクリプトの場合は、ファイルを直接実行せずに内容を渡す形に変えると出力が返りました。
sh -c "$(cat /tmp/test.sh)"issueの報告者自身は、npmのシムを直接nodeで呼ぶ方法やpowershell.exe -Command "..."経由で呼ぶ方法も有効だったと報告しています。いずれもshebang経由のサブプロセス実行そのものを避ける点で、上記のsh -cラップと原理は同じです。
~/.bashrcを一時的にリネームする
原因が.bashrcの存在そのものだったため、ファイルを退避すると症状が消えることも報告されていました。
mv ~/.bashrc ~/.bashrc_backup
# Claude Codeを起動して作業
mv ~/.bashrc_backup ~/.bashrc修正に至るまでの経緯
コミュニティ報告とAnthropicの対応をバージョン順に並べると、次のような流れになります。
コミュニティ側ではkarl-keysingularity氏が「v2.1.7では問題なく、v2.1.8から壊れる」という報告を残しており、回帰の混入時期をピンポイントで示す数少ない証言になっています。issue自体は2026年4月30日、claude[bot]による「fixed as of version 2.1.27」という自動応答のコメントとともにクローズされました。
Windows対応はこの前後の時期に他の変更も重なっています。同じくBashツールがらみでは、EINVALエラーで失敗する別の不具合がv2.1.55で修正されました。出力が空になるのか、明示的なエラーが出るのかで原因が異なるため、症状を混同しないよう注意が必要です。さらにその後のv2.1.120では、Git Bash自体が無い環境でもPowerShellツールが自動で使われるようになりました。
今の環境が対象かを確認する方法
claude --versionでバージョンを確認する。v2.1.30以降なら今回の不具合の対象外です- v2.1.30より前のバージョンで症状が再現する場合、
~/.bashrcの有無を疑います。空のファイルでも影響したという報告があるため、中身の有無は判断材料になりません - npm経由のCLIで出力が消えるなら、
.cmd拡張子を明示して切り分けます。.cmdで出力が返れば、シム経由の実行が原因と絞り込めます - v2.1.30以降なのに同じ症状が出る場合は、この記事で扱った不具合とは別原因の可能性が高いです。別途調査してください
よくあるつまずき
.cmd拡張子の回避策は万能ではありません。拡張子違いの実行ファイルが別途存在するコマンド限定の対処で、自作の.shスクリプトには適用できませんsh -cでスクリプト内容を渡す方法は、直接実行との挙動差に注意が必要です。スクリプト内で$0や自身のパスを参照する処理があると、直接実行時と結果が変わることがあります- 原因はshebangの有無に依存し、スクリプトの中身では変わりません。「特定のコマンドを削ったら直った」といった切り分けは的外れになりがちです
まとめ
Windows版Claude CodeのBashツールには、shebang付きスクリプトを実行するとstdoutが消える不具合があり、原因は~/.bashrcの存在に関する内部処理でした。npm経由のCLIツールが軒並み出力なしになるという実害があったため、当時は.cmd拡張子の明示や.bashrcの一時退避といった回避策が広く共有されています。修正はv2.1.27で一度入り、環境によって外れていた分がv2.1.30で再修正されました。現行バージョンを使っていればこの不具合には遭遇しません。同じ症状が今出ている場合は、まずバージョンを確認したうえで別原因を疑ってください。