strictPluginOnlyCustomizationでskillsやhooksをプラグインに絞る

strictPluginOnlyCustomizationとは

strictPluginOnlyCustomizationは、skills・agents・hooks・MCPサーバーの4つを、プラグインと管理設定からしか読み込まなくする設定キーです。ユーザーのホームディレクトリにも、プロジェクトのリポジトリにも、これらの拡張を置けなくなります。

スコープはManagedだけです。managed-settings.json、MDM、サーバー管理設定のいずれかで配布したときに効きます。既定は未設定で、何もロックされません。

値の書き方は2通りあります。

• true: 4面すべてをロックする
• 配列: "skills" "agents" "hooks" "mcp" のうちロックしたい面だけを名前で並べる

skillsとhooksだけをロックし、agentsとMCPは従来どおりにする例は次のとおりです。

{
  "strictPluginOnlyCustomization": ["skills", "hooks"]
}

公式の設定リファレンスは、strictPluginOnlyCustomization.skillsのようなサブキーも索引に並べています。ただし型の欄が示すとおり、実体は独立したキーではありません。上の配列に入れる文字列です。

4面はそれぞれ何を止めて、何を残すか

ロックの中身は面ごとに違います。ここを取り違えると、ロックしたつもりで抜け道が残ります。

skillsは移行作業を先に済ませておく

個人が手元で作ったskillは、ロック後に使えなくなります。ロックの前に、社内で使われているskillをプラグインへ移す作業が要ります。移行の流れはClaude Codeプラグイン化の移行手順にまとめています。

allowManagedHooksOnlyとの違いは「プラグインを通すか」

hooksだけを見ると、既存のallowManagedHooksOnlyと役割が近く見えます。違いはプラグインの扱いです。

前者はプラグインの出所をstrictKnownMarketplacesで絞る構成と相性がよく、後者は個々のプラグインを組織が選ぶ構成向きです。設定リファレンスも、審査済みのhookを組織のマーケットプレイス経由で配る使い方を挙げています。

allowManagedHooksOnlyは、hook以外にも影響が及びます。公式の設定リファレンスには次の挙動が書かれています。

• commandソースのプラグインは、管理設定のenabledPluginsで強制有効化したものも含めて無効になる。disableCommandPluginSourcesを明示的にfalseにしたときだけ例外
• マーケットプレイスのheadersHelperコマンドも、disableCommandPluginSourcesを明示的にfalseにしない限り止まる(v2.1.238以降)
• エージェントのfrontmatterに書いたhookも止まる
• ステータスラインとファイル候補(fileSuggestion)は、管理設定に書いたものだけが読まれる
• hookに依存する/goalコマンドは、このキーがある間は実行できない
• 他のインストール済みプラグインのmodsも止まる

これらは連鎖的に止まる項目で、詳細はallowManagedHooksOnlyの解説にあります。一方、strictPluginOnlyCustomizationのhooksロックの説明が挙げる対象は、ユーザー・プロジェクト・ローカルのsettings.jsonのhookだけです。ステータスラインや/goalは出てきません。周辺の挙動まで巻き込むかどうかも、二つのキーを選ぶ材料になります。

strictKnownMarketplacesと組み合わせて供給網を閉じる

公式は、strictPluginOnlyCustomizationとstrictKnownMarketplacesを組み合わせて、拡張の供給網全体を制御することを想定しています。役割は次のように分かれます。

• strictKnownMarketplaces: ユーザーが追加・インストールできるマーケットプレイスのソースを許可リストで絞る
• strictPluginOnlyCustomization: プラグインと管理設定以外の経路を閉じる

片方だけでは穴が残ります。プラグインだけに絞っても、誰でも任意のマーケットプレイスからプラグインを入れられるなら、個人のskillを自作プラグインとして持ち込めます。逆に許可リストだけを敷いても、~/.claude/skills/に置いたskillはそのまま読まれます。

両方をmanaged-settings.jsonに書いた例です。ここでは自社のGitHub組織のマーケットプレイスだけを許可しています。

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/plugins" }
  ],
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/plugins" }
    }
  },
  "strictPluginOnlyCustomization": true
}

extraKnownMarketplacesは、許可したマーケットプレイスを全員の環境に自動登録するための項目です。strictKnownMarketplacesだけだと、ユーザーが/plugin marketplace addで自分で足す手間が残ります。許可ソースの書式(githubのオーナーワイルドカードやhostPatternなど)はstrictKnownMarketplacesの書式解説に任せます。

MCPについて、許可リストと拒否リストで個別サーバーを管理する設計はManaged MCPの許可リスト解説にあります。mcpをロックするとユーザーとプロジェクトのサーバー定義が丸ごと読まれなくなるので、allowedMcpServersで個別に通す運用とは発想が違います。

綴り間違いと型違いでは結果が逆になる

配列に書いた面の名前が、そのバージョンの知らないものだった場合、Claude Codeは設定ファイル全体を失敗にせず、その名前を無視します。新しい面が追加されたときに、全クライアントの更新を待たず名前だけ先に足せるようにするための挙動です。

一方、値そのものが真偽値でも配列でもないときは、trueとして扱われて4面すべてがロックされます。この2つのフォールバックはv2.1.282以降が対象です。

認識されなかった名前は、ステータスの注記に件数として出ます。綴りの確認はそこで行えます。

反映の確認と、ロック前に見ておくこと

管理設定が読み込まれたかは、対象マシンのClaude Codeで/statusを実行して確かめます。見るのはSetting sourcesの行です。管理設定が効いていればEnterprise managed settingsが並び、括弧内に(file)、(plist)、(HKLM)、(remote)など採用された配布元が出ます。

/status

この行が出ないときは、管理設定ファイルが置き場所のパスにあり、ポリシーキーを含んでいるかを見ます。サーバー管理設定ならclaude doctorが取得結果を報告します。別の配布元が表示されるなら、優先度が上の配布元が勝っていて、Skipped sourcesの行(v2.1.242以降)にこちらの配布元が出ます。

ロックが効いているかの実地確認は、ユーザー側に~/.claude/skills/のテスト用skillを1つ置き、スラッシュコマンドの候補に出てこないことを見るのが手早い方法です。hooksならsettings.jsonに試験用のhookを書き、発火しないことを見ます。

導入前に洗い出しておくと、配布後の混乱が減る点は3つあります。

1. 各チームのskills・agents・hooksの置き場。リポジトリの.claude/配下にあるものは、ロック後に読まれなくなる
2. プラグインとして配り直す先のマーケットプレイスがあるか
3. .mcp.jsonで運用しているMCPサーバーを、プラグイン同梱かmanagedMcpServersへ移せるか

配列指定なら面を1つずつ足せるので、広げる順序は次のような形が考えられます。順序は一例です。

ロック以外の絞り方とは何が違うか

読み込みを絞るだけなら、起動オプションにも手段があります。claude --helpには、読み込みを絞る起動オプションとして次の2つが載っています。

claude --help | grep -A10 -e "--safe-mode"

  --safe-mode                           Start with all customizations
                                        (CLAUDE.md, skills, installed plugins,
                                        hooks, MCP servers, custom commands and
                                        agents, output styles, workflows, custom
                                        themes, keybindings, and more) disabled
                                        — useful for troubleshooting a broken
                                        configuration. Admin-managed (policy)
                                        settings still apply. Auth, model
                                        selection, built-in tools and plugins,
                                        and permissions work normally. Sets
                                        CLAUDE_CODE_SAFE_MODE=1.

--setting-sourcesは、読み込む設定元をuser、project、localから選ぶオプションです。skillsのドキュメントも、userを外して起動したセッションではユーザーのskillsが読まれないと書いています。

起動オプションは起動する人が選ぶので、組織の統制には使えません。トラブルシュート用の切り分けとして、ロックと役割が分かれます。

skillsとMCPとサブエージェントとhooksの役割の違いを先に押さえたい場合はClaude Code SkillsとMCPの違いが参考になります。

ゲートウェイ配布では、親から渡ったこのキーをロックで止められない

Claude appsゲートウェイでは、ゲートウェイ(親)が配下のクライアントへ設定を渡します。管理側にはロックが5つ用意されていて、親から渡る値の多くはこれで遮断できますが、strictPluginOnlyCustomizationはその例外に挙がっています。親がこのキーを渡すと、どのロックを設定していてもフィルタを通過し、Claude Codeは開発者自身のカスタマイズを無視します。無視される中には、開発者が入れた保護用のhookも含まれます。公式は「どのロックもこれを止めない」と書いています。

ゲートウェイを使わない通常の配布では関係しない話です。ゲートウェイ配布の環境で、親がtrueか"hooks"を含む配列を渡すと、hooksの面もsettings.json側から止まります。保護用のhookは、管理設定かプラグインの側に置いておけば動き続けます。

まとめ

プラグインの出所まで絞るには、strictKnownMarketplacesとの併用が前提です。棚卸しが済んだ面から配列で足すか、全チームの移行が済んでからtrueで一括にするかは、現場の移行の進み具合で決まります。