【重複購入のご注意】この記事は「AI開発者の手帖」がnoteで販売している同名記事（Claude Code で止めたい操作を本当に止める：deny・フック・サンドボックスの選び方と置き場所を操作ごとに決める）と同じ内容です。すでにnoteで購入・閲覧できる方は重複購入にご注意ください。
Claude Code を自分の Mac や Linux で使い、settings.json の deny ルールで止めたい操作を止めているつもりの方に向けて書きます。組織で managed settings を配る管理者の運用全体と、サンドボックスが動かないネイティブの Windows は対象外です。
筆者は Claude Code の設定や権限の仕組みを公式資料と照らして追ってきました。本稿は、権限・サンドボックス・mods の概要・mods の管理・managed settings・設定の一覧・フックのガイドの各ページとchangelogを2026年10月3日に取得して突き合わせたものです。 公式の記述と筆者の整理は分けて書きます。
何が変わったか
changelog によると、10月1日の 2.1.287 で mods が入りました。mods の概要によると、既定でオンです。mod はプラグインに入った関数で、ツール呼び出しを確認の前に承認できます。
権限のページによると、deny ルールが mod より優先されるのは、managed settings のある端末か、Team・Enterprise プランでログインしているときだけです（既定の扱いで、組織は変えられます）。それ以外では、mod は deny ルールが拒否する呼び出しも承認できます。組織の管理が無い個人の端末はこちらです。しかも mods の管理のページによると、deny が優先される環境でも、mod が自分でファイルを読む $.fs やプログラムを起動する $.process には deny が効きません。
権限のページと mods の管理のページをもとに、mod が deny ルールを越えられるかを環境ごとに筆者がまとめたものです。左の列は、managed settings のある端末か Team・Enterprise でログインしている場合の既定の扱いで、組織はこれを変えられます。
もともと deny だけでは止まらない
権限のページは、Bash のルールはセキュリティの境界ではなく、Bash(rm *) は /bin/rm や bash -c 'rm ...' を止めないと書いています。Read の deny は、grep -r や自分でファイルを開くスクリプトには効きません。逆にサンドボックスの読み取り拒否は、組み込みの Read ツールを止めません。
層ごとに届かない経路が違うので、止めたい操作ごとに経路を並べ、どの層で塞ぐかを決める必要があります（筆者の整理）。
判定表から1操作だけ見せます
有料部の判定表は、操作ごとに「経路 → 塞ぐ層 → 置く場所 → 確かめ方と判定条件」を並べています。git push の項目の一部です。
- 経路：git push origin main。公式の表が止まらないと書く git -C . push origin main・git 'push' origin main。スクリプトの中の push。mod の承認
- 塞ぐ層：deny ルールは最初の形だけを止めます。PreToolUse フックも命令文の文字列を見るだけなので、境界はサンドボックスに置きます。HTTPS の push は通信先の制限で止め（リモートのホストを許可リストに入れず、strictAllowlist をオンにした場合）、作業ディレクトリの外のローカルのリモートへの push は書き込み制限で止めます（その場所が filesystem.allowWrite・additionalDirectories などの追加の書き込み許可にも、一時ディレクトリにも含まれない場合）
- 置く場所：deny は user settings。mod にこの deny を越えさせないには、置き場所の managed settings にファイルを置いて組み込みの守りを読み込ませます（mod 自身の $.fs・$.process は別。この優先が効いているかを直接確かめる方法は用意していません）
- 判定条件：Claude に Bash で push させ、ツールの結果に出た拒否の理由（権限のルールによる拒否か、サンドボックスによる拒否か）を見ます。理由が出ない失敗や未実行は未判定です。同じ形の push が、書き込みを許した場所のダミーのリモートへは通ることも対照として見ます
関連する記事
許可ルールの効き方が変わった例として、2.1.280 から symlink 越しの書き込みが綴りだけの allow では通らなくなった件と、その直し方を実測で扱った記事です。ルールを書いたあとに、実際に効いているかを確かめる考え方が共通します。
参考になったら、記事下部のライクとXの共有ボタンから応援してもらえるとうれしいです。
続きで読めるのは、6操作（秘密ファイルの読み取り、削除・上書き、外部への送信、git push、認証情報の環境変数、守りの設定を緩める操作）それぞれの経路と、公式の仕様に基づく層の選び方と置き場所（user settings・プロジェクト・managed settings・--settings）、settings.json の雛形（user settings 用と managed settings 用）と置く前の控え・戻し方、mod の止め方とそれぞれで止まらないもの、Claude Code が拒否の理由を返す経路の確かめ方、層を選ぶ判断図です。環境変数と守りの設定を緩める操作の経路、mod に対して deny が優先されていることは、確かめ方を用意していません（確かめられない経路は本文に明記しています）。では、止めたい操作ごとに、どの経路をどの層で塞ぎ、どこに置けば、mod や別の書き方に越えられずに済むのか。
この記事の販売者
