Manage mods for your organization

原典: Manage mods for your organization ／日本語版

一行要約

何も設定しなければ mod はオンで、組み込みのガード（sec-default@builtin）が managed なものと deny ルールを守る。ただしガードが読み込まれるのは managed settings のあるマシンか Team / Enterprise のサインインのときだけで、deny ルールは Claude のツール呼び出しにしか効かず、mod 自身の $.fs / $.process は止めない。

要点

何もしないとどうなるか

mod はオン（v2.1.286 以降）。ユーザーは許可された marketplace から入れても、--plugin-dir で読んでもよい
組み込みのガードが先に走る —— ユーザーは切れない。読み込まれるのは、マシンに managed settings があるか、Team / Enterprise でサインインしているときだけ。API キーや Bedrock / Agent Platform / Foundry で認証するユーザーは、managed settings のあるマシンでしかガードを得ない
ガードが守るもの —— ユーザーの mod は、managed hook が受け取るもの・決めること、system prompt、managed の CLAUDE.md などの指示、mod が設定として読むもの、managed MCP サーバのツールと説明、を変えられない
それ以外は許される —— ファイルの読み書き、プロセス起動、ネットワーク、ツール呼び出しやプロンプトの書き換え、拒否、確認が出るはずの呼び出しの承認、画面の描画。すべてユーザーの権限で

deny ルールと managed hook が勝つが、及ぶ範囲に穴がある:

Where the guard loads, a user’s mod can’t approve a call that a deny rule refuses, whichever settings file holds the rule. A block from a PreToolUse hook in managed settings is final too. Both apply to Claude’s tool calls. Neither applies to a mod’s own $.fs and $.process calls: with Read(.env) denied, a mod can still read that file with $.fs.read or start a program that does.

ガードが読み込まれる環境では、ユーザーの mod は deny ルールが拒む呼び出しを承認できない（ルールがどの設定ファイルにあっても）。managed settings の PreToolUse hook のブロックも最終である。どちらも Claude のツール呼び出しに効くもので、mod 自身の $.fs と $.process の呼び出しには効かない —— Read(.env) を deny していても、mod は $.fs.read でそのファイルを読めるし、読むプログラムを起動もできる。

ガードの外では覆せる: ユーザーの mod は、ask ルールの確認や、managed でない PreToolUse hook のブロックを覆して承認できる。auto mode では、mod が承認した呼び出しは分類器を通らない。

既存の制御はどう残るか

settings hook はそのまま（非推奨にもなっていない）
managed hook が先に走る —— managed の PreToolUse hook は mod より先に呼び出しを見て、そのブロックは最終。mod が呼び出しを書き換えたら、managed hook は書き換え後にもう一度走る。他の設定ファイルと plugin の PreToolUse hook は最後の mod の後に走るので、ツールを走らせずに自分の結果を返す mod はそれらを走らせない
ネットワークのポリシーは $.http.fetch に効くが、$.process.run で起動したプログラムには効かない（ユーザー自身のアクセスでネットに出る）
plugin の制御は mod にも効く（strictKnownMarketplaces など）
確認プロンプトは描き直せない
未信頼のディレクトリでは、trust の確認に答えるまで mod は読み込まれない
--safe-mode は組織のものも含め、入れた mod を止める

None of these controls sandboxes a mod. A mod you allow runs as the user, with the user’s access to files, processes, and the network.

どの制御も mod をサンドボックスに入れはしない。 許可した mod は、ユーザーとして、ユーザーのファイル・プロセス・ネットワークへのアクセスで動く。

ポリシーの選び方

望むこと	設定
入れた mod を一切走らせない（hook はそのまま）	ガードの `allowManagedModsOnly`、組織の mod は配らない
入れた mod も hook も一切走らせない（managed hook も）	`disableAllHooks: true`
組織の mod だけ	`allowManagedModsOnly` ＋組織の mod を「組織のもの」と数えられる形で入れる
承認した marketplace の mod なら何でも	marketplace の制限＋ `disableSideloadFlags: true`
何でもよいが、組織の mod が他を検査する	組織の mod を入れ、`sec-default@builtin` と一緒に `prependPlugins` に並べる

allowManagedModsOnly は pluginConfigs の cc-plugin-sec-default@builtin の下に置く。managed settings からしか読まれない（user / project / local / --settings に書いても何も変わらない）。ユーザーの settings hook・status line・/goal は動き続ける。GitHub など remote の marketplace から有効にした plugin の mod は「ユーザーのもの」に数えられる
allowModsToOverrideDenyRules: true にすると、ユーザーの mod が deny ルールの拒否を覆して承認できる
ガードは fail closed —— managed settings を読めなければユーザーの mod を全部拒否し、承認された呼び出しの deny ルールを確かめられなければその呼び出しを拒否する
disableAllHooks を managed に置くと、managed の PreToolUse hook も何も止めなくなる
CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=0 で止めていたなら置き換える —— v2.1.287 以降は無視される

入れる前に mod を審査する

claude plugin validate の calls: 行で見るもの: $.fs.read / $.fs.write（ユーザーが触れるどこでも）、$.process.run / spawn（ユーザーとしてプログラムを起動）、$.http.fetch、$.env.get / $.settings.read（API キーを持ちうる）、$.env.set（以後に起動するコマンドと MCP サーバの環境を変える）、$.mcp.call、$.model.complete（ユーザーのプランか API キーを使う）、$.prompt.submit（ユーザーの言葉としてプロンプトを送れる）、$.session.send。hooks: 行の tool.call / prompt.submit はすべてのツール呼び出しとプロンプトを見て変えられること、tool.check は承認・拒否できることを意味する。このコマンドが読めない形で mods API を使う mod は、そもそも読み込まれない。

組織の mod を走らせる

「組織のもの」と数えられる条件: managed の enabledPlugins が true、managed settings がその marketplace をユーザーのマシン上のディレクトリとして絶対パスで指す、marketplace が plugin を相対パスで載せる（その場で読まれる）。キャッシュにコピーされる plugin（GitHub / git / URL / npm）は、managed で有効にしても「ユーザーのもの」。ディレクトリは管理者だけが書けるようにする —— 書ける人は mod を書き換えられる。

順序: prependPlugins の mod は他のすべての mod より先に見て、結果を最後に見る（変える・拒む・ユーザーの mod を飛ばす）。appendPlugins はユーザーの mod の後で、通された形のイベントだけを見る。prependPlugins を設定したら sec-default@builtin も並べないとガードが消える。

ポリシー mod の注意: plugin.register hook が例外を投げるか時間切れになると、その検査は fail open（検査中の mod は読み込まれる）。.catch で拒否を返して fail closed にする。hooks のワーカーが3回落ちると、組み込み以外の mod は組織のものも含めて外れる（/reload-plugins か新しいセッションまで）。

そのまま使える具体例

{
  "pluginConfigs": {
    "cc-plugin-sec-default@builtin": {
      "options": { "allowManagedModsOnly": true }
    }
  }
}

（managed-settings.json に置く。原典そのまま）

確かめ方:

claude --plugin-dir ./first-mod   # mod の hook が走らず、ガードのメッセージが出れば効いている
claude --debug                    # 組織の mod は "tier prepend"、拒否された mod は "refused by cc-plugin-sec-default: ..."

原典で言及されている関連文書

mods-overview — mod とは何か
mods-events — mod が走る順序
permissions — deny ルールと mod の関係
plugins — plugin の制御が mod にも効く

ai-docs

エクスプローラー