Claude CodeのProtected pathsとCritical pathsの違い

Claude CodeにはProtected pathsとCritical pathsという、名前が紛らわしい2つの安全装置があります。Protected pathsは.gitや.claudeなど特定のファイル・ディレクトリへの書き込みを止めます。Critical pathsはファイルシステムのルートやホームディレクトリを狙ったrm・rmdirによる削除を止めます。対象が「書き込みか削除か」で分かれている点が最大の違いです。bypassPermissionsモードでは挙動まで逆転します。この記事では両者の判定基準・モードごとの挙動に加えて、見落としやすいもう1つの保護レイヤーまでを追います。権限モード全体の変遷はClaude Code権限モデルの変遷で扱っています。

Protected pathsとCritical pathsの根本的な違い

Protected pathsは「特定のファイル・ディレクトリ」を書き込みから守るリストです。対象は固定されていて、.gitや.claude、シェルの起動ファイルなど、書き換えられるとClaude Code自身の挙動や権限設定が変わってしまうものに限定されます。読み取りは対象外で、あくまで書き込み(Edit・Write・リダイレクトを含むBashコマンド)だけが検査されます。

Critical pathsは逆に「どんなファイルか」を問いません。ファイルシステムのルート、ホームディレクトリ、作業ディレクトリとその親といった場所そのものが対象で、そこに向かうrm・rmdirの削除コマンドだけを検査します。中身が何であっても、rm -rf /やrm -rf ~のような操作は同じ扱いです。

つまりProtected pathsは「このファイルは特別だから書き込みを見る」、Critical pathsは「この場所は特別だから削除を見る」という別々の設計思想でできています。書き込みは細かい単位で、削除は広い単位で守る。この非対称性が、名前の似た2つの機能が別々に存在する理由です。

Protected pathsは特定ファイルの書き込みを検査する

Protected pathsに含まれるディレクトリは.git、.config/git、.vscode、.idea、.husky、.cargo、.devcontainer、.yarn、.mvn、そして.claudeです。Claude Code自身がgit worktreeを置く.claude/worktreesだけは除かれます。ファイル側は.gitconfigや各シェルの起動ファイル(.bashrc、.zshrc等)、.npmrc、.mcp.json、.claude.jsonなどです。いずれも書き換わると設定や認証情報が変わってしまうものです。

書き込みが止まるのはdefault・acceptEditsモードだけではありません。planモードでも、バイパス許可があるセッションを除けば同様にプロンプトが出るか、auto modeが使えるなら分類器に回されます。プロンプトなしで通るのはbypassPermissionsモードと、バイパス許可があるプランニングセッションです。auto modeでは分類器の判定次第になります。dontAskモードはそもそも拒否します。

Claude Code v2.1.248以降、--restrictedフラグ付きのセッションではこの扱いがさらに絞られます。分類器がProtected pathsへの書き込みを承認できなくなり、auto modeであってもプロンプトを経由します。

重要なのは、settings.jsonのpermissions.allowルールがこの判定を素通りできないことです。.claude/**をEdit許可ルールに登録していても、Protected pathsの安全確認はallowルールの評価より先に走ります。そのため、プロンプトが出るモードでは.claude/settings.jsonへの書き込みは相変わらずプロンプトされます。プロンプトには「Yes, and allow Claude to edit its own settings for this session」という選択肢が出ます。これを選ぶと、そのセッション内では以降の.claude/書き込みが確認なしで通るようになります。

{
  "permissions": {
    "allow": ["Edit(.claude/**)"]
  }
}

このルールを設定しても、.claude/settings.json自体への書き込みはProtected pathsの確認が先に走るため止まったままです。allowルールが効くのはProtected paths以外の.claude/配下のファイルに対してだけです。

Critical pathsはrm・rmdirの削除だけを検査する

Critical pathsが対象にする「場所」は次の5種類です。

• ファイルシステムのルート
• ルート直下のトップレベルディレクトリ(/usrや/etcなど)
• ホームディレクトリ
• Windowsのドライブルートとその直下(C:\やC:\Windows)
• 作業ディレクトリとその親

追加の作業ディレクトリ(additionalDirectories)も対象になりますが、条件が1つ付きます。rm -rf <dir>/*のようにグロブで指定したときだけが対象で、ディレクトリそのものを指定したrm -rf <dir>は対象外です。シェル変数配下のグロブ(rm -rf "$DIR"/*)も同じ扱いです。変数が空だとルート削除になりうるためです。$(...)によるコマンド置換の中に隠しても判定は素通りしません。

削除コマンドがCritical pathsに当たったときの挙動は、書き込みへの安全確認とは別のルールで決まります。allowルールにマッチしていても、PreToolUseフックが"allow"を返していても、Critical pathsのrm・rmdir削除は承認されません。これはモデルの判断ミスに対するサーキットブレーカーとして設計されており、matchするdenyルールだけが例外的に効いて操作をブロックします。

明示的なaskルールがマッチする場合、auto modeでもプロンプトが出ます。Claude Code v2.1.218以降では、auto modeにおいてallowルールが完全一致していても、Critical pathsの削除は必ず分類器を経由するようになりました。それ以前のバージョンでは、狭いallowルールが分類器を素通りするケースがありました。その裏返しの強化です。分類器自体の判定基準はClaude Codeのauto mode分類器は何を止めているかで扱っています。

bypassPermissionsモードで挙動が逆転する

ここがProtected pathsとCritical pathsの違いが最もはっきり出る場面です。bypassPermissionsモードはすべての権限プロンプトと安全確認を無効化し、Protected pathsへの書き込みも含めてツール呼び出しを即座に実行します。ところがCritical pathsのrm・rmdir削除だけは、このモードでも引き続きプロンプトで確認されます。

書き込みは通す、削除だけは止める。同じ「最も緩いモード」の中で正反対の扱いを受けるのは、両者の設計目的が違うからです。Protected pathsは「うっかり自分の設定ファイルを書き換えてしまう」事故を防ぐもので、隔離されたコンテナやVM前提のbypassPermissionsではその心配が薄れます。一方Critical pathsは「ファイルシステムのルートやホームディレクトリを丸ごと消す」ような操作へのサーキットブレーカーです。隔離環境であっても取り返しがつかないため、最も信頼度の高いモードでも外れません。

bypassPermissionsは--dangerously-skip-permissionsフラグやプラン中のバイパス許可経由で有効になります。ただしClaude Code on the webは、セッション開始時にこの設定を無視します。そのためここで説明した書き込み許可・削除確認の挙動差は、ローカルCLIやVS Code拡張、Desktopアプリなどバイパス許可が使えるセッションに限られます。

サンドボックスにも別の保護パスリストがある

「protected paths」という言葉は、実はもう1か所で別の意味に使われています。Bashサンドボックスが持つ独自のprotected pathsです。こちらは権限モードの安全確認とは別のレイヤーで動きます。権限システムのProtected pathsは「ツールを実行する前に承認するかどうか」を決めます。対してサンドボックスのprotected pathsは、書き込みが許可されたディレクトリの中で、すでに実行中のコマンドを対象にします。設定ファイルやコードの読み込み元を書き換えられないようにするための、実行後の防波堤です。

サンドボックス側のリストは4グループに分かれます。

• 作業ディレクトリとその上位にある.claudeの設定ファイル群
• 作業ディレクトリだけにあるシェル起動ファイルや.git/hooks
• 作業ディレクトリをベアリポジトリに変えてしまうHEADやobjectsなどのgit内部ファイル
• ~/.claude配下の大半と認証情報ストア

このリストはallowWriteエントリやEditのallowルールで上書きできません。外す方法はsandbox.filesystem.disabledでサンドボックスのファイルシステム分離自体を切ることだけです。

つまり、権限システムのProtected pathsをすり抜けてBashコマンドが実行されたとしても、サンドボックスが有効なら二重のチェックが働きます。ただしこのサンドボックス側の保護は、対応環境が限られる点に注意が必要です。Windows上のPowerShellツールでは、プレビュー期間中はサンドボックス自体が未対応と公式ドキュメントに明記されています。Windows環境で削除操作を止めているのは、権限モードのCritical pathsチェックだけということになります。PowerShellのRemove-ItemはrmのCritical pathsリストとは別の専用ルールで検査されます。

実務でどちらを意識すればいいか

自動化ワークフローを組むときにこの表が効きます。.claude/配下を書き換えるスクリプトを自動承認したい場合、Protected pathsの仕組み上allowルールでは突破できません。プロンプトへの応答をPermissionRequestフックで自動化するか、その部分だけ手動運用に残すか、どちらかを選ぶことになります。逆に「削除さえ止まれば安心」という設計なら、Critical pathsのサーキットブレーカーが効きます。bypassPermissionsでも生きているため、他の操作をそのモードで流してもルート削除だけは人の確認を経由します。

まとめ

Protected pathsは特定ファイル・ディレクトリへの書き込みを、Critical pathsはファイルシステム上の危険な場所へのrm・rmdir削除を、それぞれ独立に検査します。allowルールやPreToolUseフックの"allow"はどちらも素通りできず、dontAskモードは両方を拒否します。もっとも対照的なのはbypassPermissionsモードで、Protected pathsへの書き込みは許可される一方、Critical pathsの削除は引き続きプロンプトが出ます。Critical pathsの判定は、auto modeにおいてallowルールが完全一致していてもv2.1.218以降は必ず分類器を経由するように強化されました。サンドボックスにも別系統のprotected pathsが存在します。こちらはWindows上のPowerShellツールでは今のところ対応していません。環境ごとの安全性を見積もるときに押さえておく価値があります。

よくある質問

Protected pathsに.envは含まれますか

公式が挙げるProtected pathsのファイル一覧に.envは含まれていません。環境変数ファイルへの書き込みを防ぎたい場合は、permissions.denyにEdit(.env)のようなルールを別途追加する必要があります。

allowルールを設定すればProtected pathsやCritical pathsを先に承認できますか

できません。どちらの安全確認も、settings.jsonのallowルールを評価するより前に走る仕組みになっているため、ルールを足しても判定そのものは変わりません。

dontAskモードではどちらも同じ扱いになりますか

はい。dontAskモードは事前承認されたツール以外を拒否する設計で、Protected pathsへの書き込みもCritical pathsの削除も、プロンプトを出さずに拒否します。ロックダウンされたCI環境向けのモードです。

追加の作業ディレクトリ(additionalDirectories)もCritical pathsの対象になりますか

対象になりますが条件があります。追加ディレクトリそのものを指定したrm -rf <dir>は対象外で、rm -rf <dir>/*のようにグロブで配下をまとめて削除する場合だけCritical pathsの判定が働きます。

PowerShellのRemove-Itemもrmと同じ基準で判定されますか

判定されません。Remove-ItemにはrmのCritical pathsリストとは別の専用チェックがあり、対象がシステムパスかワイルドカードかで挙動が変わります。PowerShell Remove-ItemがClaude Codeでブロックされる条件では、その3つの判定パターンを一次ソースから具体的にまとめています。