Claude Codeの権限ルールの罠｜黙って効かない指定

Claude Code の設定ファイルに Write(docs/**) のような deny ルールを書いて、「これで書き換えを止めた」と安心していないでしょうか。実はそのルール、エラーにもならず、警告も出ないまま、何も止めていない可能性があります。

結論から書きます。Claude Code のファイル権限チェックが見ているのは Edit(path) と Read(path) の2つだけです。Write(path)・NotebookEdit(path)・Glob(path) という書き方は設定として受理されるのに、チェック側から一度も参照されません。2026年7月14日リリースの v2.1.210 で、この形のルールに起動時警告が出るようになりました。裏を返せば、それ以前のバージョンでは警告すら出ずに黙って無効化されていたということです。

株式会社Fyve では Claude Code を無人で動かす運用を続けており、権限設定は「事故が起きてから気づく」類の領域だと考えています。だからこそ私は、この警告を「表記ゆれの指摘」ではなく安全設計の穴の通知として受け取りました。この記事では、何が効かないのか・なぜ効かないのか・自分の設定をどう点検するかを、実際に手を動かす順番で整理します。

v2.1.210 で追加された起動時警告の中身

公式リリースノート（v2.1.210・2026年7月14日）には、次の一文が追加されました。

Added a startup warning for Write(path), NotebookEdit(path), and Glob(path) permission rules — use Edit(path) or Read(path) instead

実際にプロジェクト設定へ Write(docs/**) の deny ルールを置いた場合、起動時にはこう表示されます。

Permission deny rule (.claude/settings.json): Write(docs/**) is not matched by file permission checks — only Edit(path) rules are. Use Edit(docs/**) instead (Edit rules cover all file-editing tools).

ここで大事なのは「非推奨になった」「書き方が古い」という話ではないことです。公式ドキュメントは、この形のルールを accepted but never matched（受理されるが、決して照合されない）と説明しています。構文エラーではないので設定は通る。通るのに、機能しない。この「静かに死んでいる」状態が、権限設定でいちばん危険な失敗の形です。

なぜ Write(path) は効かないのか

直感に反する部分なので、仕組みを押さえておきます。Claude Code のファイル権限チェックは、ツール名ごとではなく「読む／変更する」という操作の種類で束ねられています。

Edit ルールは、ファイルを編集する組み込みツール全体に適用される（Write や NotebookEdit もこの傘の下に入る）
Read ルールは、ファイルを読む組み込みツール全体に適用される（Grep や Glob、プロンプト内の @file 参照にも及ぶ）

つまり Edit(path) と Read(path) が代表選手であり、パス指定の権限ルールはこの2つしか受け付けません。Write(docs/**) と書いた人は「Write ツールを止めたい」と思っているのですが、チェック側には「Edit の傘」しか存在しないため、そのルールは誰にも参照されないまま放置されます。

この罠が厄介なのは、Write が実在するツール名だからです。存在しないツール名を書いたわけではないので、字面はどこまでも正しく見える。実際、設定ファイルの別の場所——たとえば hook の matcher ——では "Write|Edit" のような指定が正しく機能します。同じ設定ファイルの中で、Write という名前が有効な場所と無効な場所が混在しているのが、この落とし穴の正体です。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

書き換え対応表

効かない書き方	正しい書き方	理由
`Write(docs/**)`	`Edit(docs/**)`	Edit ルールが全ファイル編集ツールを覆う
`NotebookEdit(docs/**)`	`Edit(docs/**)`	同上
`Glob(docs/**)`	`Read(docs/**)`	Read ルールが全ファイル読取ツールを覆う

効かない権限ルールと正しい書き方の対応表。Write(path)・NotebookEdit(path)はEdit(path)へ、Glob(path)はRead(path)へ書き換える

一方で、パスを付けないツール名だけのルールは影響を受けません。Write という deny ルール（括弧なし）は、そのツールをあらゆる場所で止める指定として正しく機能し、警告も出ません。「Write を全面禁止」は有効、「Write を特定パスだけ禁止」は無効——この線引きが分かれ目です。

もう一つの穴: Read の deny は Edit を止めるが、そこ止まり

v2.1.208 以降、Read の deny ルールは同じパスに対する Edit ツールもブロックします（新規ファイル作成を含む）。読めない場所は書き換えもできない、という素直な挙動です。

ただし公式ドキュメントは、ここに注釈を付けています。Write と NotebookEdit はこの巻き込みの対象外です。したがって「どのツールにも変更させたくないパス」には、Read の deny だけでなくEdit の deny を明示的に足す必要があります。読み取りを塞いだから安全、とは言えません。

バージョンによっては警告すら出ない

この起動時警告は v2.1.210 以降の機能です。私が手元で確認したところ、稼働中の環境は v2.1.209 でした。つまりこの環境では、仮に効かないルールが混ざっていても警告は一切出ません。

ここが実務上いちばん重要な点だと考えています。警告は「今から壊れるもの」を教えてくれるのではなく、ずっと前から効いていなかったものを、ようやく可視化しただけです。バージョンを上げるまで沈黙が続くのであれば、更新を待つのではなく、自分の設定を今すぐ目視で点検するほうが速い。私はそう判断しました。

自分の設定を点検する

設定ファイルは複数のスコープに分かれて存在するため（この構造はClaude Code settings.json設定ガイドで整理しています）、1か所だけ見ても足りません。パス指定付きの Write / Glob / NotebookEdit ルールを横断で洗い出します。

grep -rnE '"(Write|Glob|NotebookEdit)\([^)]+\)"' \
  .claude/settings.json .claude/settings.local.json ~/.claude/settings.json

ヒットした行が、あなたが書いたつもりで一度も機能していないルールです。上の対応表に沿って Edit(...) / Read(...) へ書き換えます。ヒットが0件なら、少なくともこの罠は踏んでいません。deny ルールの設計そのものはClaude Codeのdeny設定の書き方で扱っているので、併せて見直すと確実です。

権限ルールを「唯一の壁」にしない

私が無人運用（Mac miniをAI自動化サーバーにする）で徹底しているのは、権限ルールを最後の砦として信用しないという一点です。今回の件は、その方針を裏付ける実例になりました。

理由は警告の有無だけではありません。公式ドキュメントが明記しているとおり、Read と Edit の deny ルールが効くのは組み込みのファイルツールと、Claude Code が認識できる範囲の bash ファイルコマンド（cat・head・tail・sed 等）までです。Python や Node のスクリプトが自分でファイルを開く場合のような任意のサブプロセスには適用されません。OS レベルで全プロセスを止めたいなら、サンドボックスを有効化する必要があります。

整理すると、権限ルールには2種類の穴があることになります。