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

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

設定を入れる前に: 何が読まれなくなり、何が残るのか

allowManagedPermissionRulesOnlyは、Claude Codeが権限ルールをどこから読むかを管理設定の1層に固定するBoolean設定です。値はデフォルトで未設定で、このときはユーザー・プロジェクト・ローカル・--settingsの各ファイルのルールが管理設定のルールに加わります。trueにすると、その加算が止まります。

ScopeはManagedです。サーバー管理設定・MDMポリシー・managed-settings.jsonファイルのいずれかで配布した値だけが効きます。ユーザー設定や.claude/settings.jsonにfalseと書いても、Managedスコープのキーなので無視されます。

{
  "allowManagedPermissionRulesOnly": true
}

trueにしたときの境界線は、「許可を広げるものは消え、制限を足すものは残る」です。

--disallowedToolsとdeny/askが残るのは、これらが制限を足すだけで、管理設定が許可した範囲を広げられないからです。v2.1.257より前は、最初の設定リロードでこれらのコマンドライン指定とセッションのルールが落ちていました。古いバージョンを配っている環境では、セッションの途中から制限が消える可能性があります。

claude --help(v2.1.287)は両フラグを次のように説明します。どちらもカンマまたは空白区切りでツール名を渡す形式で、trueの間に効くのは--disallowedTools側だけです。

claude --help

--allowedTools, --allowed-tools <tools...>
    Comma or space-separated list of tool names to allow (e.g. "Bash(git *) Edit")
--disallowedTools, --disallowed-tools <tools...>
    Comma or space-separated list of tool names to deny (e.g. "Bash(git *) Edit")

起動フラグ側の使い分けは、allowedTools/disallowedToolsの記事に詳しくあります。対話中にルールを見たり編集したりする/permissionsの使い方は、/permissionsコマンドの記事を参照してください。

スキルのallowed-toolsも読まれなくなる(v2.1.282以降)

権限ルールの話はスキルにも及びます。スキルのfrontmatterにはallowed-toolsを書けて、スキルを呼び出したときのツールを承認なしで通せます。このキーをtrueにすると、v2.1.282以降のClaude Codeは次の置き場所にあるスキルとコマンドのallowed-toolsを無視します。

• リポジトリの.claude/ディレクトリ
• ~/.claude/skills/と~/.claude/commands/(claude.aiから同期されたスキルを含む)
• --add-dirで追加したディレクトリ
• ~/.claude/skills/かプロジェクトの.claude/skills/の中にある、.claude-pluginマニフェスト付きのプラグイン

マーケットプレース、claude.ai、npmから入れたプラグインも、v2.1.284以降は自分のツールをallowed-toolsで事前承認できません。Anthropicの公式ソースか、管理設定が保証したソースのプラグインだけが事前承認を保ちます。管理設定から配られたスキルと同梱スキルもallowed-toolsを保ちます。スキル側のdisallowed-toolsも有効なままです。無視されたスキルのツールは、管理設定のルールと通常の権限プロンプトを通ります。無視されたスキルが何本あるかは、セッション内の/statusで一覧できます。

リポジトリに入っているスキルのallowed-toolsは、ワークスペースを信頼していなくても適用されます。このキーを使うと、その経路を組織単位で閉じられます。

Coworkの作業フォルダへの書き込みが止まる

Claude DesktopアプリのCoworkは、Claude Codeの上でセッションを動かします。ユーザーが接続したフォルダなどへのアクセスは、セッション起動時にCoworkが渡すallowルールで与えられます。

管理設定でこのキーがtrueだと、そのallowルールは親設定・--allowedTools・設定ファイルのどの形で渡されても落ちます。接続フォルダへの書き込みが事前承認されなくなるわけです。編集前に確認するモードのCoworkセッションでは、Coworkが確認画面を出せないため、書き込みのたびにClaudeが「保護された場所か、接続フォルダの外のパスにあたるため」とブロックを報告します。

対処は、そのフォルダへのallowルールを管理設定側に足すことです。MDMで配っている端末では、別のmanaged-settings.jsonではなくMDMポリシーに足します。ファイル形式の例は次のとおりです。

{
  "allowManagedPermissionRulesOnly": true,
  "permissions": {
    "allow": [
      "Edit(~/CoworkProjects/**)"
    ]
  }
}

CoworkProjectsはユーザーのホーム直下にあるフォルダの例なので、実際に接続させるフォルダに置き換えます。以後、新しいCoworkセッションではそのフォルダ配下にファイルを保存できます。パスの書き方(絶対パスの//形式を含む)は、権限ルールのRead/Edit節にあります。

親設定を持つホストアプリとの関係

Claude Desktopのような埋め込みホストは、親設定としてポリシーを渡せます。既定では、管理ソースが1つでもあれば、親設定は丸ごと無視されます。

最優先の管理ソースでparentSettingsBehaviorを"merge"にすると、親設定のうち制限側の値だけが取り込まれます。ただし"merge"のフィルターには抜け穴があり、ホストのallowルールとサンドボックスの許可リストは通ってしまいます。このallowを落とすのが、allowManagedPermissionRulesOnlyの役目です。

管理ソースのどれか1つでもこのキーを設定していれば、より優先度の高いソースがキーを持たなくても、親設定のallowルールとadditionalDirectoriesは落ちます。denyとaskは残ります。

残す側にも例外があり、パターンが!で始まるRead/Editルールは落ちます。ホストが!ルールで管理ルールの一部を抜け道にすることはできません。この点は、このキーの有無にかかわらず同じです。--disallowedToolsやセッションのルールの!は落ちませんが、削れるのは同じソース内のルールだけです。管理設定のdenyは削れません。

複数の管理ソースを併用するときの合成

管理設定の配布経路は1つとは限りません。サーバー管理設定(claude.aiまたはゲートウェイ経由)、macOSのplistやWindowsのHKLMレジストリによるMDMポリシー、managed-settings.jsonファイルが併存することがあります。どれが効くかはmanagedSourcesBehaviorで決まります。

既定の"first-wins"では、ポリシーキーを持つ最上位のソース1つがポリシー全体を供給し、下位のソースは「全ソースから読まれるキー」しか寄与しません。下位のmanaged-settings.jsonがallowManagedPermissionRulesOnly: trueを書いていても、最上位がポリシーキーを持っていれば効きません。

"merge"にすると(v2.1.242以降)、このキーは「Lock」の種別として合成されます。どのソースであれ厳格な値(true)があれば、それが最上位でなくても採用されます。誰も厳格な値を設定していないときだけ、最上位ソースの緩い値が使われます。同じLock種別にはpermissions.disableBypassPermissionsModeもあり、合成規則は共通です。

"merge"には注意点が1つあります。下位のソースのpermissions.allowのようなリスト型のキーも、そのまま方針に加わります。"merge"は、最上位より下位にあるソースがすべて管理者の管理下にある環境だけで使います。

反映されているかを確かめる手順

ロールアウトの途中で「この端末にポリシーが届いたか」を確かめる方法は2つあります。順に実行します。

/statusは、allowed-toolsが無視されたスキルの一覧を見るときにも使います。設定の置き場所そのものは、Claude Code組織管理ガイドに整理があります。

値を壊したときは「true扱い」になる

管理ソースがこのキーを読めない値(型違いなど)で書いていた場合、Claude Codeはそのキーを緩い値に倒しません。allowManagedPermissionRulesOnlyのように制限側の値が1つに決まるキーは、直すまで「その制限値」として読まれます。レポートにはwas present but invalidと出て、扱われている値が併記されます。nullを書くとキー自体が消える点は別扱いです。

allowManagedMcpServersOnlyとは別のキー

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

片方をtrueにしても、もう片方の制御は動きません。MCPサーバーの追加経路まで塞ぎたい組織は、両方を明示的に設定します。

向いている組織と、先に決めておくこと

このキーが解決するのは、権限ルールの発生源がリポジトリごとにばらつく問題です。各リポジトリの.claude/settings.jsonにBash(curl *)のようなallowルールが積み上がると、どこまでの操作が確認なしに通るかが揃わなくなります。trueにすれば、許可を広げる変更は必ず管理設定の更新を経由し、許可範囲の変遷は管理設定の差分で追えます。

一方で、開発者の手元の運用は変わります。「一度許可したら以後は聞かない」が使えなくなるため、確認プロンプトの回数は増えます。Bashの定番コマンド(git statusなど)やテストの実行は、管理設定のallowにあらかじめ載せておくと、現場の負担を抑えられます。

permissions.defaultModeのような他のキーも同じ管理設定に置けます。このキーは「最上位のソースだけから読む」種別なので、"merge"にしても下位ソースの値は使われません。たとえばdefaultModeをacceptEditsにして編集は自動で進め、Bashだけallow/ask/denyで個別に絞る、という組み合わせが成立します。設定ファイル全体の構造はClaude Code settings.json完全ガイドで押さえられます。

よくあるつまずき

ユーザー設定のallowが突然効かなくなる: ルールを足してきた開発者から「許可したはずのコマンドが毎回聞かれる」と報告が来たら、まず/statusで管理ソースにこのキーが入っていないかを見ます。ユーザー設定側のルールは壊れたわけではなく、読まれなくなっています。

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

すべての制限が消えると誤解する: 消えるのは許可を広げる経路で、--disallowedToolsやセッションのdeny/askルールはv2.1.257以降ずっと効き続けます。

下位ソースのtrueが効かない: "first-wins"のままだと、最上位のソースにポリシーキーがある限り、下位のmanaged-settings.jsonは寄与しません。/statusのSkipped sourcesで、無視されているソースを確かめます。

まとめ

allowManagedPermissionRulesOnlyは、許可を広げる経路だけを管理設定へ集める鍵です。入れる前に、権限ルールに頼っているスキルやCoworkの作業フォルダが管理設定のallowに載っているかを洗い出しておくと、配布後の混乱を避けられます。複数の管理ソースを併用する組織は、managedSourcesBehaviorの値で合成結果が変わるため、端末の/statusで効いているソースを確かめておくと安心です。