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月、AnthropicのGitHub Issueトラッカーに報告されました。スレッドには2025年8月から10月にかけて20件のコメントが集まり、報告されたClaude Codeのバージョンは1.0.62から2.0.22までと幅が広く、単発の環境依存ではなく、Windows + Git Bashという組み合わせに共通する問題です。起票時点のv1.0.62から、v1.0.72・v1.0.90・v1.0.95・v2.0.22といった後続バージョンでも同様の再現報告が続いており、複数回のアップデートをまたいで残り続けた不具合であることがわかります。ファイルが消せずGitのコミットを妨げたという報告もあり、放置しづらい種類の不具合でした。Issueの起票者自身も、この不具合が毎回必ず起きるわけではなく「発生するタイミングは、特定のコマンド経路やエラー処理の内容に依存するかもしれない」という所見を残しています。

なぜ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が経由していないためと結論づけています。MSYS2のアクセス経路そのものは、この報告からは特定できません。

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

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

影響の大きさも一様ではありません。あるユーザーはGit操作のたびにnulファイルが紛れ込んでコミットを妨げると報告し、別のユーザーは利用しているソース管理ツール(Plastic SCM)の履歴が壊れかねないと述べています。7-Zipで圧縮する過程でファイルを削除させるという回避策を編み出した報告もあり、Windows標準の手段では手も足も出ない状況だったことがうかがえます。

表のadditionalDirectoriesのケースは、WindowsとWSLで設定を使い分けている環境で起きやすく、パスの書式の混在はwslInheritsWindowsSettingsの仕組みと設定方法で扱っている論点とも重なります。

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

すでにnulファイルが作成されている場合、アクセスに使う手段によって削除できるかどうかが変わります。

Git Bashが使える環境では、次のコマンドで削除できます。

rm nul

Git Bashが使えない場合は、コマンドプロンプトからフルパスの先頭に\\?\を付けて削除する方法が報告されています。Microsoftのドキュメントによれば、\\?\プレフィックスはWindows APIの文字列解析処理そのものを無効化し、渡した文字列をファイルシステムへそのまま送る働きをします。

del "\\?\C:\path\to\project\nul"

Issueの報告の中には、Claude Code自身に「作成したnulファイルを削除して」と依頼したところ解決したという声もありました。別のユーザーは、自分では管理者権限がないと削除できなかったnulファイルを、Claude Codeがあっさり削除してくれたと報告しています。

v2.1.69で修正済み

この不具合は、Claude Code v2.1.69(2026年3月5日公開)で修正されています。公式changelogは「Git Bashでモデルが2>nulを使うとリテラルなnulファイルが作成される問題を修正した」と明記しており、Issue #4928もクローズ済みです。

同じ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で更新すれば、v2.1.69以降と同様にこの問題は起きなくなります。

Git Bashを経由するツール実行に共通する落とし穴

nulファイルの一件は、単発の表示バグというより、WindowsのCMD構文とUnix系シェルの構文がGit Bash上で混在しうるという構造に起因していました。v2.1.69以降は、Git Bash内で2>nulが使われてもnulファイルが作られなくなっていますが、changelogは結果だけを記しており、内部でどう対応したかまでは明らかにされていません。

パスの書式がWindows形式とUnix形式で混在した場合など、nul以外の場面でも同種のずれが起きる余地は残っています。Windowsネイティブ・Git Bash・WSL2を併用する開発フローでは、コマンドがどちらの流儀で解釈されているかを意識する場面がまだあります。

まとめ

Claude CodeがWindowsで作るnulファイルは、Windowsの予約デバイス名とGit Bashの構文解釈が絡んで生じていた不具合です。原因はモデルがGit Bash内でWindowsのCMD構文2>nulを使ってしまうことにあり、Claude Code v2.1.69以降はこのnulファイルが作られなくなっています。すでにnulファイルができてしまった場合は、Git Bashのrm nulか、フルパス先頭への\\?\指定で削除できます。

v2.1.69で修正されているため、バージョンを確認してもなお発生する場合は、.claude/settings.local.jsonのパス指定がUnix形式のままになっていないかを見直すと、切り分けの手がかりになります(v2.1.69より前の環境で報告されていた原因の一つです)。