allowManagedPermissionRulesOnlyで権限ルールを管理設定だけに縛る

allowManagedPermissionRulesOnlyをmanaged-settings.jsonでtrueにすると、Claude Codeは権限ルールの発生源を管理設定1つに絞ります。ユーザー・プロジェクト・ローカルの設定ファイルにあるallow/ask/denyルールは無視され、--allowedToolsフラグも効かなくなります。常時許可の選択肢は権限プロンプトから消え、新しいルールの保存も止まります。開発者が自分の設定でこっそり許可を広げる経路を断つための鍵です。

allowManagedPermissionRulesOnlyは何を固定するのか

allowManagedPermissionRulesOnlyは、Claude Codeが権限ルールをどこから読むかを1つの層に固定するBoolean設定です。値はデフォルトで未設定(unset)で、このとき権限ルールはユーザー・プロジェクト・ローカル・--settings・管理設定のすべてから合成されます。trueにすると、合成先が管理設定だけに変わります。

ScopeはManagedです。サーバー管理設定・MDMポリシー・managed-settings.jsonファイル・ポリシーヘルパーのいずれかからしか反映されません。ユーザー設定や.claude/settings.jsonに書いても無視されます。この扱いは他のManagedスコープキーと共通です。組織の管理者だけがオン/オフを決められる設計です。

managed-settings.json自体の配布手順や、managed settings全体の優先順位はClaude Code組織管理ガイドに整理があります。ファイルの置き場所や反映のタイミングで迷ったら、まずそちらを確認してください。

{
  "allowManagedPermissionRulesOnly": true
}

managed-settings.json以外の配布経路

Managedスコープのキーはmanaged-settings.jsonファイルだけでなく、複数の経路から配布できます。サーバー管理設定は管理コンソールから配信され、端末側は起動時にフェッチします。MDMポリシーはmacOSのplistやWindowsのHKLMレジストリに書き込む形で配布します。加えて、実行可能ファイルの出力を使うpolicyHelperという経路もあり、この場合はヘルパーが起動時に計算したmanagedSettingsオブジェクトがそのまま管理設定として扱われます。

どの経路を使ってもallowManagedPermissionRulesOnlyの意味は変わりません。違うのは「誰が」「いつ」値を決められるかです。静的なファイル配布では値は固定ですが、policyHelperを使えば端末の所属部署やネットワーク位置に応じて動的にtrue/falseを出し分けることもできます。

trueにすると何が無効になるのか

効果は4つに分かれます。1つ目は、ユーザー・プロジェクト・ローカル・--settingsファイルのpermissions.allow/permissions.ask/permissions.denyルールが無視されること。2つ目は、--allowedToolsフラグが効かなくなること。3つ目は、権限プロンプトの常時許可の選択肢が非表示になること。4つ目は、新しいルールの保存自体が止まることです。

つまり開発者は、確認プロンプトが出るたびに個別で許可するしかなくなります。「一度だけ許可して以後は聞かない」という運用がまるごと封じられる点が、このキーの本体です。対話中に権限ルールを個別確認・管理する/permissionsコマンドの挙動も、管理設定だけを読む前提に変わります。コマンド自体の使い方は/permissionsコマンドの記事にまとめてあります。

一方で無効にならないものもあります。--disallowedToolsフラグと、そのセッションが持つdeny/askルールはtrueの間もそのまま効きます。これはClaude Codeがセッション途中で設定を再読み込みしたあとも変わりません。

プロジェクトの.claude/settings.jsonにあるallowルールは、通常はワークスペース信頼ダイアログを承認して初めて適用されます。allowManagedPermissionRulesOnlyがtrueの間はプロジェクト側のallowルール自体が読まれなくなるため、信頼ダイアログの承認状況にかかわらず適用されません。

設定が実際に反映されているかどうかは、セッション内で/statusコマンドを実行し「Setting sources」の欄を見れば確認できます。管理設定の配布経路が複数ある環境では、どのソースが権限ルールを供給しているかをここで確認するのが確実です。

なぜdenyとaskだけ生き残るのか

--disallowedToolsとセッションのdeny/askルールが生き残るのは、これらが制限を追加するだけのルールだからです。管理設定が許可した範囲を、ユーザー側がさらに絞ることはできても広げることはできません。許可を広げる経路(allowと--allowedTools)だけを塞ぎ、制限を狭める経路は残す。これがallowManagedPermissionRulesOnlyの設計の芯です。

同じ非対称性は、埋め込みホスト(Claude Desktopなど)から渡される親設定の扱いにも表れます。Claude Codeは親設定を管理tierの一部として扱いますが、そこに含まれるdenyとaskルールだけを保持し、allowルールとadditionalDirectoriesは落とします。ホスト側のアプリが「読み書きの範囲を広げる」設定を持っていても、管理者が引いた境界より外には出られない仕組みです。

allowManagedMcpServersOnlyとは何が違うのか

名前が似ているallowManagedMcpServersOnlyは、対象がまったく別です。allowManagedPermissionRulesOnlyはBash・Read・Edit・WebFetchなどツール呼び出し全般のallow/ask/denyルールを対象にします。一方allowManagedMcpServersOnlyは、MCPサーバーをどこから追加できるかの許可リスト(allowedMcpServers)だけを管理設定に縛ります。

一方をtrueにしても、もう一方の制御は動きません。MCPサーバーの追加経路も同時に塞ぎたい組織は、両方を明示的に設定する必要があります。逆にMCPサーバーのdenylist(deniedMcpServers)はどちらのキーとも独立していて、常にすべてのファイルから合成されます。

複数の管理ソースを配布したときの合成ルール

組織がサーバー管理設定・MDMポリシー・managed-settings.jsonファイルを複数併用すると、allowManagedPermissionRulesOnlyの扱いはmanagedSourcesBehaviorの値で変わります。

既定の"first-wins"では、ポリシーキーを持つ最上位のソースの値がそのまま採用されます。下位のソースがallowManagedPermissionRulesOnly: trueを書いていても、最上位のソースがこのキーを持たなければ無視されます。

managedSourcesBehaviorを"merge"にした場合(v2.1.242以降)だけ、扱いが変わります。このキーは「Lock」種別に分類され、どのソースであれ厳格な値(true)を設定していれば、それが最優先ソースでなくても採用されます。厳格な値をどこも設定していないときだけ、最上位ソースの緩い値(falseまたは未設定)が採用されます。つまり"merge"配下では、下位の管理ソースがtrueを書き足すだけで、上位ソースが何も指定していなくても権限ルールが管理設定へ固定されます。組織の一部門だけがmanaged-settings.jsonで先にこのキーを有効化しておく、という段階的な締め付けが機能する設計です。

同じLock種別にはpermissions.disableBypassPermissionsModeも含まれています。bypassPermissionsモードへの移行そのものを禁止するキーで、複数の管理ソースを併用する構成ではallowManagedPermissionRulesOnlyと同じ「厳格側が勝つ」ルールで合成されます。権限まわりのロックを組み合わせて配布する組織は、この2つが同じ合成規則に従う点を覚えておくと設計しやすくなります。

どんな組織がこのキーを使うのか

このキーが解決するのは、権限ルールの発生源がプロジェクトごとにばらつく問題です。個々のリポジトリの.claude/settings.jsonにBash(curl *)のようなallowルールが積み上がっていくと、どのプロジェクトでどこまでの操作が確認なしに実行されるかが揃わなくなります。監査のたびにリポジトリを1つずつ見て回る必要も出てきます。

allowManagedPermissionRulesOnlyをtrueにすれば、許可を広げる方向の変更は必ず管理設定の更新を経由します。情報セキュリティ部門がmanaged-settings.jsonを1か所で管理していれば、許可範囲の変遷は設定ファイルの差分だけで追えます。個々のエンジニアが自分のプロジェクトで許可を足す判断そのものを、組織側に移す設定だと言えます。

管理設定ではpermissions.defaultModeのような他のManagedスコープキーも同時に配布できます。たとえばdefaultModeをacceptEditsにしてファイル編集は自動で進めつつ、Bashコマンドの可否だけは管理設定のallow/ask/denyで個別に絞る、という組み合わせも成立します。どちらのキーも「ユーザー側の設定では上書きできない」という性質は共通です。

よくあるつまずき

MCPサーバーの追加まで止まると思い込む: 前述のとおりallowManagedPermissionRulesOnlyはMCPサーバーの許可リストを縛りません。MCPサーバーの追加まで管理設定に縛りたいときはallowManagedMcpServersOnlyを別途設定します。

ユーザー設定で上書きできると思い込む: ~/.claude/settings.jsonに"allowManagedPermissionRulesOnly": falseと書いても、ScopeがManagedのキーはユーザー設定から読まれないため無視されます。無効化できるのは管理設定を配布する側だけです。

すべての制限が消えると誤解する: trueにした直後は、--disallowedToolsやセッションのdeny/askルールまで一緒に無効化されると誤解しがちです。実際に消えるのは許可を広げる経路だけで、制限を追加するルールはv2.1.257以降ずっと効き続けます。

settings.json全体の構造を把握せずに設定キーだけ足す: permissions配下のキーは他にもdefaultModeやadditionalDirectoriesなど多数あり、相互に影響します。設定ファイル全体の構造を先に押さえたい場合はClaude Code settings.json完全ガイドが役立ちます。起動時のツール許可フラグとの役割分担で迷う場合は、allowedTools/disallowedToolsの記事を参照してください。

まとめ

allowManagedPermissionRulesOnlyは、組織が権限ルールの発生源を管理設定1つに固定するためのキーです。効くのは「許可を広げる経路」だけで、--disallowedToolsやセッションのdeny/askルールのような制限側は素通りします。MCPサーバーの許可リストは対象外なので、そちらも縛りたければallowManagedMcpServersOnlyを別途設定します。複数の管理ソースを併用する組織は、managedSourcesBehaviorを"merge"にした瞬間にこのキーの合成ルールが変わる点を押さえておく価値があります。設定後は/statusで反映元のソースを確認してから、対象範囲を段階的に広げるのが安全です。