Claude CodeでWindowsのnulファイルが生成される原因と消し方

Claude CodeでWindowsにnulという名前のファイルができる

Claude CodeをWindows上のGit Bashで使っていると、作業ディレクトリにnulという名前のファイルが生成されることがあります。Windowsはnulを通常のファイル名として認めておらず、本来は存在しないはずのファイルです。中身はほとんど空か、Claude Codeが実行したコマンドの標準エラー出力がそのまま書き込まれています。

通常のWindowsコマンドプロンプトで2>nulを使う分には、これは正しい構文です。標準エラー出力をNULデバイスへ捨てるだけで、実体のあるファイルは作られません。Issueの起票時点の記述でも、期待される挙動は「2>nulを使ってもファイルは作られないこと」と明記されています。問題が起きるのは、この構文をGit Bashという別のシェル環境の中でそのまま実行したときだけです。

この現象は2025年8月1日、v1.0.62の報告としてAnthropicのGitHub Issue #4928に起票されました。Issueには180件を超えるコメントが集まり、再現報告はv2.0.8やv2.0.22、v2.1.7、v2.1.12と長い期間のバージョンにまたがっています。単発の環境依存ではなく、Windows + Git Bashという組み合わせに共通する不具合でした。起票者自身も、発生は毎回ではなく「特定のコマンド経路やエラー処理に依存するかもしれない」と書いています。

放置しづらい不具合だった理由は、被害の出方にあります。git add .がinvalid path 'nul'で止まる報告、nulをコミットしたリポジトリがWindowsでクローンできなくなった報告、Unityのプロジェクトで再インポートが繰り返された報告が並んでいます。Plastic SCMの履歴が壊れかねないという声もありました。gitのindexにnulが入ると、checkoutやstash、rebase、reset --hardが通らなくなったという報告もあります。

2>nulはCMDでは正解、Git Bashではファイル作成になる

2>nulは、コマンドプロンプト(CMD)では標準エラー出力を捨てる正しい書き方です。Git Bashのようなbash系シェルでは、同じ文字列が「nulというファイルへ書く」指示になります。

なぜnulという名前だけが特別なのか

WindowsはCON・PRN・AUX・NUL・COM1からCOM9・LPT1からLPT9をシステム予約の名前として扱い、通常のファイル名には使えません。Microsoftの公式ドキュメントは、これらの名前を拡張子付きで使った場合(たとえばNUL.txt)も同じ予約名として扱われると明記しています。

NULとは、Unix系OSでいう/dev/nullに相当する、書き込みを破棄するWindowsの予約デバイス名です。Windowsのコマンドプロンプトではcommand 2>nulと書けばエラー出力を捨てられ、Unix系シェルのcommand 2>/dev/nullとちょうど同じ役割を果たします。この2つの構文がほぼ同じ見た目で意味だけ違う点が、今回の不具合の起点になっています。

Windowsがこれらの名前を今も予約し続けているのは、シリアルポートやプリンタポートといった周辺機器へのアクセス方式を、内部のNT名前空間として今のWindowsにも残しているためです。Microsoftのドキュメントは、COM1からCOM9のようなデバイス名がNT名前空間の一部として定義され、後方互換のために現在のバージョンのWindowsでも引き続きサポートされていると説明しています。NULも同じ枠組みに属する名前で、通常のファイル名として使うことを想定していません。

Git Bashが予約語チェックをすり抜ける仕組み

Claude CodeはWindows上でGit Bashをコマンド実行の環境として使えます。Issueに寄せられた報告によると、Claude(モデル)がコマンドを組み立てる際に、Unix向けの/dev/nullではなくWindowsのCMD構文である2>nulを、Git Bashの中でそのまま実行してしまうケースがありました。

なぜGit Bash上でだけnulが実体のあるファイルになるのか、Issue上ではある報告者が手元の挙動から次のように説明しています。Git Bashからcat nulやrm nulを実行すると普通のファイルとして読み書きできる一方、同じファイルにPowerShellからCannot find path、File Explorerのプロパティ画面からは空欄、Get-FileHashコマンドレットからはPath does not existという結果が返ってきたというものです。この報告者は、この違いをWin32 APIの予約名チェックをGit Bashが経由していないためと結論づけています。

同じ仕組みは、WindowsでなくてもPOSIX系のシェルなら手元で再現できます。macOSのbashで、存在しないディレクトリを2>nul付きでlsしてみた結果です。

cd "$(mktemp -d)"
bash -c 'ls /no/such/dir 2>nul'
ls -l nul
cat nul

ls -lは通常ファイルのnulを示し、catするとls: /no/such/dir: No such file or directoryというエラー文が入っています。2>/dev/nullなら何も作られません。POSIX系のシェルにとってnulは特別な名前ではなく、2>nulは「nulという名前のファイルへ書く」という指示にしかなりません。

実際に報告された発生パターン

Issueのコメント欄には、nulファイルが生成されるきっかけとして複数のパターンが寄せられています。共通しているのは、Unix向けの2>/dev/nullではなくWindows CMD構文の2>nulがGit Bashの中でそのまま実行された形跡がある点で、コマンドを実行した操作の種類は設定ファイルの読み込みからGit操作まで様々です。

表のadditionalDirectoriesのケースは、Unix形式のパスを書いていたことが原因だったという報告です。パス書式の混在はwslInheritsWindowsSettingsの仕組みと設定方法で扱っている論点とも重なります。

nulファイルができてしまったときの消し方

Issueには、アクセス経路ごとに消せたかどうかの報告が集まっています。PowerShellのRemove-Item nulは「パスが見つからない」で失敗し、File Explorerの右クリック削除も失敗する例が多く報告されています。消せた方法は次のとおりです。

Git Bashなら次の1行です。

rm nul

PowerShellで\\?\を使う場合は、ワイルドカード展開を避ける-LiteralPathを付けた形で報告されています。

Remove-Item -LiteralPath "\\?\C:\path\to\project\nul" -Force

コマンドプロンプトならdel "\\?\C:\path\to\project\nul"の形です。Claude Code自身に「作ったnulファイルを削除して」と頼んだら消えたという声もあり、管理者権限がないと消せなかったファイルが消えたという報告もあります。

v2.1.69で修正済み

この不具合は、Claude Code v2.1.69(2026年3月5日公開)で修正されています。Issue #4928はこの修正の6日前にクローズされており、changelogの該当項目はタイムラインに載せたとおりです。

同じv2.1.69では、Windows関連の不具合として「worktreeのファイルコピーがWindowsで動作しない問題」と「グローバルな.claudeフォルダの検出がWindowsで動作しない問題」も同時に修正されています。Windows向けの修正が3件まとめて入りました。Git for Windowsの導入やCLAUDE_CODE_GIT_BASH_PATHによるパス指定など、Git Bash自体のセットアップはClaude Code Windowsインストールにまとめています。

手元の環境がv2.1.69より前かどうかは、次のコマンドで確認できます。

claude --version

v2.1.69より古いバージョンでnulファイルの生成を繰り返す場合は、claude updateで更新すると、changelogに載った修正が入ります。

更新できない環境で報告された予防策

v2.1.69より前のバージョンを使い続ける場合、Issueでは生成を止める方法ではなく、できたファイルを素早く片付ける方法が共有されています。

フックの入力JSONに作業ディレクトリがcwdとして入ることは、フックのドキュメントに載っています。Issueに投稿された回避策は、BashツールのPostToolUseでNode.jsのスクリプトを呼び、そこでnulを削除する形でした。設定側は次のようになります。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "node .claude/hooks/windows-nul-fix.js" }
        ]
      }
    ]
  }
}

スクリプト側は、標準入力のJSONからcwdを読み、rmSync(path.join(cwd, "nul"), { force: true })で消すだけの内容です。

Git Bashがない環境でも起きるのか

起票時のClaude CodeはWindowsでGit Bashを前提にしていましたが、v2.1.120(2026年4月28日)で「Git for Windows(Git Bash)は必須でなくなった」とchangelogに載りました。Claude Codeのシェルツールが、Git for Windowsの有無でどう変わるかは次のとおりです。

nulの件が解決しても、WindowsネイティブとGit BashとWSL2を併用する開発フローでは、コマンドがどのシェルの流儀で解釈されるかを意識する場面が残ります。Issueにも、Claudeがls C:\path\to\directory 2>nul | findstrのようにバックスラッシュのパスとCMD構文をBashに持ち込んだ例が投稿されています。

まとめ

nulファイルは、Git Bash上のモデルが書いたCMD構文2>nulが、POSIX系シェルでは通常のファイル作成になるために起きていました。v2.1.69以降のバージョンなら作られず、できてしまったファイルはGit Bashのrm nulで消せます。