Claude Media
disableSideloadFlagsでサイドロード用CLIフラグを拒否する

disableSideloadFlagsでサイドロード用CLIフラグを拒否する

Managed設定のdisableSideloadFlagsは、strictKnownMarketplacesを迂回する--plugin-dir等4つのCLIフラグを起動時に拒否します。

disableSideloadFlagsでできること

disableSideloadFlagsは、--plugin-dir--plugin-url--agents--mcp-configという4つの起動時CLIフラグを一括拒否するManaged設定です。設定先はmanaged-settings.json・MDMプロファイル・server-managed settingsのいずれかです。これらのフラグは本来、その場限りで外部のプラグイン・サブエージェント定義・MCPサーバーを読み込ませる機能です。strictKnownMarketplacesでマーケットプレイスを許可リスト化していても、1回の起動に限ってはこのフラグ経由で迂回できてしまいます。disableSideloadFlagstrueにすると、この抜け道を塞げます。Claude Code v2.1.193以降が対象です。

塞げるのは起動時フラグ経由の読み込みだけです。claude mcp addコマンドや.mcp.jsonファイルでのMCPサーバー追加はこの設定ではブロックされません。個々のサーバーを名前単位で制御したい場合は、後述のallowedMcpServersと組み合わせます。

拒否される4つのフラグと起動時の挙動

disableSideloadFlagsを有効にすると、Claude Codeは次の4フラグを起動時に検出し、拒否したフラグ名を含むエラーを表示して終了します。

フラグ本来の用途
--plugin-dir本来の用途ローカルディレクトリのプラグインを直接読み込む
--plugin-url本来の用途URL指定でプラグインを読み込む
--agents本来の用途サブエージェント定義を起動時に注入する
--mcp-config本来の用途MCPサーバー設定を起動時に読み込む

この判定は、これらのフラグを内部的に使う起動経路にも及びます。対象はデスクトップアプリのCoworkのローカルセッションです。拒否は起動時点で行われるため、指定されたプラグインディレクトリやMCP設定ファイルへの読み取りアクセス自体が発生しません。

クラウドセッション(Claude Code on the web)では挙動が異なります。サーバー側から--mcp-configでMCPサーバーが渡されても起動自体は止めず、インプロセスのtype: "sdk"エントリを除くサーバーを除外してセッションを開始します。v2.1.239より前は、サーバー配信の--mcp-configがあるとクラウドセッションの起動自体が失敗していました。あわせて、セッション開始後にサーバー側から追加されるMCPサーバーの更新も無視します。この経路はクラウドセッション設定や、Agent SDKのsetMcpServers()をリモートワーカーで使う場合に通ります。

インプロセスのtype: "sdk"だけで構成された--mcp-configは、disableSideloadFlagsが有効でも常に受け入れられます。Agent SDKやVS Code拡張機能が使う起動経路はこの形を取るため、影響を受けません。

設定方法

Managed設定にしか書けません。プロジェクトやユーザーのsettings.jsonに書いても無効です。

{
  "disableSideloadFlags": true
}

配布先はmanaged-settings.json・MDMプロファイル・claude.ai管理コンソールのserver-managed settingsのいずれかです。managed-settings.jsonの設置場所はOSごとに違い、macOSは/Library/Application Support/ClaudeCode/、Linux/WSLは/etc/claude-code/、WindowsはC:\Program Files\ClaudeCode\です。設定が届いているかどうかは、対象マシンでClaude Codeを起動して/statusを確認します。

/status

Setting sourcesの行に管理ポリシーの取得元が表示されます。表示されない場合は配布経路を見直します。managed settingsの階層構造や配布メカニズム全般はClaude Code組織管理ガイドにまとめています。

Managed設定はどのタイミングで反映されるか

Managed設定を配布する経路は4つあり、Claude Codeが設定を読み直すタイミングがそれぞれ違います。claude.ai管理コンソールやセルフホストのClaude apps gatewayから配るserver-managed settingsは、起動時に取得したうえで1時間ごとにポーリングします。MDMやOSレベルのポリシーは起動時に読み込み、その後30分ごとに変更の有無を確認します。managed-settings.jsonファイルは起動時に読み込むだけでなく、ファイルが変更されるたびに読み直します。Windows・WSLのHKCUレジストリだけは位置付けが違い、他のいずれの経路もポリシーキーを配っていないときに限って使われます。

disableSideloadFlagsをtrueに変更したら、この読み込みタイミングを踏まえて反映を確認します。managed-settings.jsonファイルを配布した場合はファイル変更時に自動で読み直されます。一方でMDMやHKCUレジストリ経由では最大30分、server-managed settingsでは最大1時間、起動済みのセッションに反映されないことがあります。急ぎで適用したい場合は、対象マシンでClaude Codeを再起動すれば起動時の読み込みで確実に反映されます。

Managed設定を読み込む面は、ターミナルだけではありません。VS CodeとJetBrainsの拡張機能、デスクトップアプリのCodeタブ、Agent SDKのセッションもすべて同じ経路でManaged設定を読み込みます。Agent SDKはsettingSourcesでユーザー・プロジェクト・ローカルの各設定ファイルを除外できますが、Managed設定はその除外の対象外です。disableSideloadFlagsを有効にしている組織では、Agent SDK経由で起動したセッションでも4フラグの拒否は同じように効きます。自前でホストする実行環境のクラウドセッションは少し特殊です。server-managed settingsがポリシーキーを何も配っていない場合に限り、実行環境のイメージに含めたmanaged-settings.jsonファイルも読み込みます。

CoworkのフルVMサンドボックスとリモートセッションには届かない

Coworkはデスクトップアプリ上でClaude Codeのセッションを動かす機能です。ただしclaude.ai管理コンソールのserver-managed settingsは、Coworkセッションでは取得しません。サインインしているアカウントがTeamやEnterpriseでも同じです。適用されるポリシーは、セッションがどこで動くかによって変わります。

  • ユーザーのマシン上で動く場合: デバイスのMDMポリシーとmanaged-settings.jsonを読みます。disableSideloadFlagsもここでは効きます
  • フルVMサンドボックス内で動く場合(requireCoworkFullVmSandbox設定時): デバイスのMDMポリシーも設定ファイルも無い仮想マシン内で動くため届きません
  • リモートCoworkセッション: Anthropicが管理するVM上で動くため、そもそも参照できるデバイスポリシーがありません

strictKnownMarketplaces・disableCommandPluginSources・allowedMcpServersとの役割分担

disableSideloadFlagsは起動時フラグだけを塞ぐ設定で、他の抜け道は別の設定が担当します。組織のプラグイン・MCPサプライチェーンを一通り塞ぐには、目的ごとに次の設定を組み合わせます。

目的使う設定対象
追加できるマーケットプレイスを制限する使う設定strictKnownMarketplaces対象/plugin marketplace addと自動更新
起動時フラグでの1回限りの読み込みを拒否する使う設定disableSideloadFlags対象--plugin-dir--plugin-url--agents--mcp-config
マーケットプレイス側が実行するコマンドでのインストールを拒否する使う設定disableCommandPluginSources対象commandソースのプラグインとheadersHelper
個々のMCPサーバーを名前単位で許可・拒否する使う設定allowedMcpServers対象claude mcp add.mcp.jsonで追加済みのサーバー

strictKnownMarketplacesはマーケットプレイスの追加元だけを見ており、そこに含まれる個々のプラグインの取得方法までは制御しません。commandソースのプラグインは許可済みマーケットプレイスからでもインストールできるため、それを止めたいならdisableCommandPluginSourcesを別途設定します。公式ドキュメントも、マーケットプレイスの許可リストとdisableSideloadFlagsをペアで設定するよう案内しています。

disableCommandPluginSourcesは既定では未設定です。ただしallowManagedHooksOnlyでフック実行をManaged設定に限定している組織では、明示的にfalseにしない限りcommandソースのプラグインも自動的に無効になります。フック統制を先に敷いている組織は、意識しないままcommandソースまで塞げていることになります。なおstrictKnownMarketplacesallowedMarketplacesという別名でも書けます(Claude Code v2.1.232以降)。表記が違う設定ファイルを見比べるときは、この別名の存在を先に確認します。

よくあるつまずき

  • .mcp.json経由の追加まで防げると思い込む: disableSideloadFlagsが拒否するのは起動時フラグだけです。プロジェクトの.mcp.jsonclaude mcp addによるサーバー追加は別経路で、止めるにはallowedMcpServersが必要です
  • VS Code拡張機能まで巻き込んで壊れると考える: VS Code拡張機能はインプロセスのtype: "sdk"エントリだけで--mcp-configを渡します。disableSideloadFlagsを有効にしても動作は変わりません。拡張機能が動かなくなった場合は別の原因です
  • Coworkの全経路を統制できたと判断する: 前述のとおり、フルVMサンドボックスとリモートCoworkにはデバイスポリシーが届きません
  • v2.1.239より前後の挙動を混同する: クラウドセッションでの--mcp-config拒否は、バージョンによって「起動が止まる」か「該当サーバーだけ除外して起動する」かが変わります。組織のバージョンを確認してから挙動を説明します
  • 設定を変更した直後に反映されないと慌てる: 配布経路によっては最大30分から1時間の遅延があります。急ぐ場合は対象マシンでClaude Codeを再起動します

まとめ

disableSideloadFlagsは、strictKnownMarketplacesで敷いたマーケットプレイスの許可リストを、起動時フラグの1回限りの利用で迂回されないようにする補完設定です。単体では完結しません。マーケットプレイスの許可リスト・コマンドソースの拒否・MCPサーバーの個別許可リストと組み合わせて、初めてプラグインとMCPサプライチェーン全体を統制できます。Coworkのフルモードやリモートセッションのようにデバイスポリシーが届かない経路が残る点は、設定前に把握しておきます。マーケットプレイスの許可リスト運用の詳細はGHESプラグインマーケットプレイスを許可リストで運用するにまとめています。個々のMCPサーバーの許可・拒否はManaged MCPで許可リスト・拒否リストを組織管理するが扱っています。

この記事を共有:XはてブLinkedIn