PowerShell Remove-ItemがClaude Codeでブロックされる条件
PowerShellのRemove-Itemはシステムパス・ワイルドカードを常に拒否し、作業ディレクトリの再帰削除だけがrmと異なる基準で判定されます。3パターンを一次ソースで確認します。
Claude CodeのPowerShellツールでRemove-Itemを実行すると、対象によって扱いがまったく違います。システムパスとワイルドカードは常に拒否、作業ディレクトリの再帰削除だけが通常の権限フローに乗ります。この3パターンを知らずに使うと2つの疑問にぶつかります。「なぜここは確認すら出さずに拒否されるのか」「なぜここはbypassPermissionsでも止まらずに実行されるのか」。どちらもWindows環境特有のつまずきです。
Claude CodeでRemove-Itemが止まる3パターン
Remove-ItemはrmのCritical pathsリストとは別に、専用のチェックを持っています。対象に応じて最初にマッチした条件が適用され、次の3通りに分かれます。
| 対象 | 挙動 |
|---|---|
| システムパス(ルート・ドライブルート・ホームディレクトリなど) | 挙動確認なしで常に拒否 |
ワイルドカード(裸の*、/*・\*で終わる指定) | 挙動分類器に届く前に確認なしで拒否 |
作業ディレクトリまたはその親への-Recurse | 挙動通常の権限モードのフローに従う |
上から2つは「絶対に止まる」パターン、3つ目だけが権限モード次第で挙動が変わる「条件付き」パターンです。この違いを押さえておくと、プロンプトが出ないからといって必ずしも実行されたとは限らない、あるいは逆に確認なしで即座に消えることもある、という2つの誤解を避けられます。
システムパスとワイルドカードは常に拒否される
システムパスに分類されるのは次の4種類です。ファイルシステムのルート、ルート直下のトップレベルディレクトリ、Windowsのドライブルートとその直下(C:\やC:\Windowsなど)、そしてホームディレクトリです。これらを対象にしたRemove-Itemは、どの権限モードで実行していてもClaude Codeが確認を求めることなく拒否します。プロンプトへの応答で許可することもできません。
ワイルドカードも同じく無条件拒否の対象です。裸の*、あるいは/*や\*で終わる指定(シェル変数配下のグロブを含む)は、権限モードのフローに乗る前の段階で拒否されます。分類器がこの対象を見る前に弾かれる点が重要で、auto modeであっても「安全な削除だから通す」という分類器の判断が介入する余地自体がありません。Remove-Item $dir/*のような一見無害に見えるコマンドも、$dirが空文字列に展開されたときのリスクを考えると、この扱いはrmのシェル変数グロブに対する判定と同じ発想です。
Remove-Item C:\
Remove-Item $HOME
Remove-Item *
Remove-Item .\build\*これらはいずれも、権限モードに関わらず確認プロンプトを経由せずに拒否される代表例です。
作業ディレクトリの再帰削除は通常の権限フローに従う
3つ目のパターンだけは扱いが違います。作業ディレクトリそのもの、またはその親を対象に-Recurseを付けて削除するコマンドは、他の承認が必要な操作と同じように扱われます。プロンプトが出るモードでは確認を求められ、autoモードでは分類器が判定し、dontAskモードでは拒否されます。
| モード | 作業ディレクトリへのRemove-Item -Recurse |
|---|---|
default / acceptEdits | 作業ディレクトリへのRemove-Item -Recurseプロンプトで確認 |
plan | 作業ディレクトリへのRemove-Item -Recurseプロンプトで確認、auto modeが使えるなら分類器へ |
auto | 作業ディレクトリへのRemove-Item -Recurse分類器が判定 |
dontAsk | 作業ディレクトリへのRemove-Item -Recurse拒否 |
bypassPermissions | 作業ディレクトリへのRemove-Item -Recurseこのチェック自体をスキップ |
3つ目の条件(作業ディレクトリまたはその親への-Recurse)に当たらないとき、つまり-Recurseが付いていない場合や対象が作業ディレクトリの範囲外の場合は、この専用チェックの対象外になり、Protected pathsや通常のファイル書き込みルールなど別の判定に回ります。ただしシステムパスとワイルドカードの拒否は-Recurseの有無と無関係に効いたままです。作業ディレクトリの外を指定した単発のRemove-Item(再帰なし)も同様に3つ目の条件には当たりません。対象がProtected paths(.claudeや.gitなど)に含まれていない限り、通常のファイル操作として扱われます。
Remove-Item -Recurse .\node_modules
Remove-Item -Recurse ..前者は作業ディレクトリの中にあるサブディレクトリを対象にした再帰削除です。-Recurseが付いている点は同じでも、対象は作業ディレクトリそのものでも親でもありません。そのためRemove-Item専用チェックの3つ目には当たりません。後者は作業ディレクトリの親を直接指定しています。この記事で説明した3パターン目に該当し、権限モード通りの確認フローに乗ります。同じ-Recurse付きコマンドでも、対象パスの位置関係だけで扱いが変わる点は見落としやすいポイントです。
acceptEditsモードでの自動承認範囲
PowerShellツールが有効なとき、acceptEditsモードはSet-Content・Add-Content・Clear-Content・Remove-Itemを対象範囲内のパスに対して自動承認します。それぞれの共通のエイリアスも同じ扱いです。ここでの「対象範囲内」は作業ディレクトリかadditionalDirectoriesの範囲内を指します。範囲外のパスやProtected pathsへの書き込みは、acceptEditsでも変わらずプロンプトされます。
つまりacceptEditsモードの自動承認は、この記事で説明した3パターンのうち「作業ディレクトリの再帰削除」の枠をさらに広げたものです。システムパスとワイルドカードの拒否がここで覆ることはなく、-Recurseの有無に関わらず対象範囲内のファイル1件を消すRemove-Itemも自動承認の対象に入ります。acceptEditsは「レビュー中のコードに手早く反復したい」場面向けのモードとして案内されているぶん、削除コマンドまで自動承認が及ぶ範囲を把握しておく価値があります。
bypassPermissionsでも例外的に素通りする理由
表の最終行が3パターンの中で唯一の例外です。bypassPermissionsモードは、作業ディレクトリの再帰削除に対するこのチェック自体をスキップします。つまりシステムパスとワイルドカードはbypassPermissionsでも変わらず拒否されますが、作業ディレクトリ配下の再帰削除だけは、他の操作と同様に確認なしで実行されます。
bypassPermissionsはもともと隔離されたコンテナやVMでの利用を前提にしたモードで、作業ディレクトリ自体が使い捨てである状況を想定しています。システムパスとワイルドカードの拒否だけは環境を問わず外れない設計になっているため、コンテナの外側にある共有ボリュームや、意図せず広いパスをマウントしている環境でも最低限の歯止めは残ります。
rmコマンドの判定との違い
同じ削除操作でも、rmとRemove-Itemでは安全装置の設計が異なります。Claude CodeのProtected pathsとCritical pathsの違いで扱ったとおり、rm・rmdirのCritical paths判定はbypassPermissionsモードでも確認プロンプトが残るサーキットブレーカーです。ところがRemove-Itemの作業ディレクトリ再帰削除は、bypassPermissionsだとそのチェック自体が外れます。同じ「最も緩いモード」でも、rm系とRemove-Item系で残る安全装置が違うということです。
もう一つの違いはタイミングです。rmのCritical paths判定はv2.1.218以降、auto modeでは、allowルールが完全一致していても必ず分類器を経由するように強化されました。プロンプトが出るモードでは分類器を経由せず確認が残ります。Remove-Itemのワイルドカード判定はそもそも分類器の手前で拒否が完結するため、allowルールの有無に関わらず分類器の判断は関与しません。判定の層が違う分、同じ「削除操作」でも読み方が変わります。
PowerShellツール自体が使えるかを先に確認する
Remove-Itemのこうした挙動は、PowerShellツールが有効になっているセッションでのみ関係します。有効化の条件は環境によって違います。
- Git BashなしのWindows: 自動的に有効
- Git BashありのWindows: claude.aiとConsoleアカウントで既定有効(Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryでは
CLAUDE_CODE_USE_POWERSHELL_TOOL=1が必要) - Linux・macOS・WSL: オプトイン。PowerShell 7以降の
pwshをPATHに通す必要がある
プレビュー期間中の制限も押さえておくべきです。PowerShellプロファイルは読み込まれず、Windows上ではサンドボックスが未対応です。サンドボックスが対応していないということは、Bashサンドボックス側が持つ独自の保護パスリストがWindowsのPowerShellコマンドには適用されないということでもあります。ここで説明した権限モードレベルのRemove-Item専用チェックが、Windows環境における実質的な唯一の歯止めになります。プロファイル未読み込みが具体的にどんな環境変数の引き継ぎに影響するかは、Claude Codeのシェル起動設定で扱っています。
まとめ
Remove-Itemはシステムパスとワイルドカードを常に確認なしで拒否し、作業ディレクトリの再帰削除だけが権限モード通りのフローに従います。この3パターン目だけがbypassPermissionsでチェックをスキップされる例外で、システムパス・ワイルドカードの拒否はどのモードでも外れません。rmのCritical paths判定はbypassPermissionsでも確認プロンプトを残すサーキットブレーカーです。Remove-Itemの作業ディレクトリ削除はそこが素通りになります。ここが実務上の最大の差です。Windows環境ではサンドボックス側の保護が今のところ効かないため、ここで説明した権限モードのチェックが唯一の歯止めになります。
よくある質問
Remove-Itemのワイルドカード拒否はauto modeの分類器で覆せますか
覆せません。ワイルドカード対象のRemove-Itemは分類器に届く前の段階で拒否が完結する設計なので、auto modeであっても分類器の判断が介入する余地はありません。
作業ディレクトリの外にある通常のファイルをRemove-Itemで消す場合はどう判定されますか
-Recurse付きで作業ディレクトリやその親を対象にする場合(3つ目の条件)を除き、この専用チェックの対象外です。ただしシステムパスとワイルドカードの拒否は-Recurseの有無と無関係に効いたままなので、対象がそのどちらでもなくProtected pathsにも含まれていなければ、通常のファイル書き込み・削除と同じ判定に回ります。
dontAskモードではRemove-Itemはどう扱われますか
作業ディレクトリへの再帰削除は拒否されます。システムパスとワイルドカードはdontAskモードに関わらずもともと常に拒否されるため、結果としてどちらのケースも実行されません。
PowerShellのrmエイリアスを使った場合も同じ判定を受けますか
rmはPowerShellではRemove-Itemのエイリアスとして解決されるため、Claude Codeが認識するコマンドはRemove-Itemと同じです。エイリアス経由だからといって判定が緩くなることはありません。