Claude Codeのドメイン許可リストを管理設定で固定するallowManagedDomainsOnly

Claude Codeのドメイン許可リストを管理者だけが決められるようにするには、managed settingsでsandbox.network.allowManagedDomainsOnlyをtrueにします。

managed settings(組織が配布する設定ファイル)でsandbox.network.allowedDomainsに許可ドメインを並べても、開発者はユーザー設定やプロジェクト設定に同じキーを1行追記するだけで、そのリストを自分の手元だけ広げられます。allowManagedDomainsOnlyはこの拡張の経路を潰す設定です。trueにすると、サンドボックス化されたコマンドが通信できるドメインはmanaged settings由来のallowedDomainsとWebFetch(domain:...)許可ルールだけになります。

許可リスト外のドメインへの接続は、プロンプトを出さずに自動で遮断されます。導入前に押さえたいのは、このキーが許可リスト以外にも効くことです。リポジトリ側の設定が無視される範囲と、ロックしても残る抜け道を順に見ます。

開発者の追記で許可ドメインが広がる仕組み

サンドボックス化されたBashコマンドは、通信できるドメインが空の状態から始まります。新しいドメインに最初に接続すると、Claude Codeは承認を求めます。「Yes, and don't ask again」を選ぶと、WebFetch(domain:...)という許可ルールがローカル設定に保存され、次回からそのドメインはプロンプトなしで通ります。

ロックがない間、allowedDomainsとWebFetch(domain:...)はセッションが読み込む全設定ファイルからマージされます。組織がmanaged-settings.jsonに社内リポジトリだけを並べていても、開発者が自分のユーザー設定に1行足せば通信先は静かに広がります。ファイルシステム側で同じ役割を果たすのがallowManagedReadPathsOnlyで読み取り再許可を管理設定に限定する設定で、こちらはallowReadという別のリストを対象にします。

managed-settings.jsonで許可ドメインを固定する

GitHubとnpmだけを許可し、開発者が追加したドメインを無視する構成は次のとおりです。

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

allowManagedDomainsOnly自体はサンドボックスを有効にしないため、enabledも併記します。この状態で開発者が自分のユーザー設定にallowedDomains: ["api.internal-tool.example.com"]を足しても無視されます。通信できるのはgithub.comと*.npmjs.orgの配下だけです。

書式はallowedDomainsもWebFetch(domain:...)も共通のルールで読まれます。github.comは全ポート、api.example.com:443は443番だけを許可します。IPv6アドレスは"[::1]"のように角括弧で囲み、v2.1.229以降が必要です。詳しい構文はIPv6ドメイン許可リストの書き方にあります。WebFetch(domain:...)側でサンドボックスが解釈するワイルドカードは、*.example.comの先頭形式と素の*の2種類です。素の*はv2.1.186以降でないと効きません。

ロックと同時に効く3つの制限

allowManagedDomainsOnlyをtrueにすると、サンドボックスは「管理者が必須にした」状態になります。このとき許可リスト以外にも次の3つが変わります。

リポジトリ設定の無視は、v2.1.285からexcludedCommands以外のキーにも広がりました。v2.1.282から284までは、ロックが無視するのはリポジトリのexcludedCommandsだけでした。v2.1.282より前は、ロックをかけていてもリポジトリがexcludedCommandsに書いたコマンドはサンドボックスの外で動き、通信制限もかからなかったことになります。

一方、開発者本人の~/.claude/settings.jsonは無視の対象外です。excludedCommandsやfilesystem.allowWriteに、managed側のロックはありません。ドメインの許可と違い、これらは開発者のユーザー設定から書けます。

strictAllowlistとの使い分け

sandbox.network.strictAllowlistも、許可リスト外のホストをプロンプトなしで拒否します。v2.1.219以降で使え、ユーザー設定・managed settings・--settingsから設定できます。リポジトリの設定ファイルに書いても効果はありません。

プロンプトに聞かれたくないだけならstrictAllowlistで足ります。開発者側からの拡張そのものを禁じたいならallowManagedDomainsOnlyの領分です。両方を有効にすると、許可リストはmanaged settings限定になり、非許可ドメインは自動で拒否されます。strictAllowlistは、読み込まれるソースのどれか1つがtrueなら有効のままで、他のソースのfalseでは無効になりません。

権限モードごとの接続の扱い

ロックの効き方は、権限モードを並べると分かりやすくなります。許可リストにないホストへ接続しようとしたとき、ロックなしの対話型ターミナルでは次のように分かれます。

strictAllowlistかallowManagedDomainsOnlyが有効なら、組み込みプロキシはどの権限モードでも拒否します。表の1行目のbypassPermissionsも例外ではなく、素通しだった接続もロックがあれば止まります。deniedDomainsに載ったホストは、ロックの有無を問わずどのモードでも拒否されます。

ドメイン許可リストはWebFetchを制限しない

allowedDomainsが縛るのは、サンドボックス内で動くBashコマンドの通信だけです。組み込みのWebFetchやWebSearchは、サンドボックスではなく権限ルールに従います。

そのため、ロックをかけてもWebFetchの可否はallowedDomainsでは決まりません。WebFetchを止めたい場合は、権限ルールのdeny側で制御します。

ロックしても残る抜け道

このロックが縛るのはallowedDomainsという「許可を広げる方向」のリストと、その周辺の経路です。deniedDomainsはロックの有無にかかわらず全ソースからマージされ続けます。開発者は組織の許可範囲の中から、さらに個別のホストを塞げます。末尾ドット付きのexample.com.も、付けないexample.comと同じ接続を遮断します。

残る抜け道は3つあります。

• サンドボックスの外で動くコマンド:excludedCommandsに一致するコマンドは、ファイルシステム制限もネットワークプロキシもなしで実行されます。ロックはサンドボックス内のコマンドにしか効かないため、ユーザー設定のexcludedCommandsは残る抜け道です。allowUnsandboxedCommands: falseとの組み合わせはサンドボックス外実行の許可設定で扱っています
• 広い許可ドメイン:組み込みプロキシは、依頼元が名乗るホスト名で許可を判断し、既定ではTLSを終端も検査もしません。github.comのような広いドメインを許可すると、ドメインフロンティングなどでその配下から許可リスト外へ通信が抜ける余地が残ります。TLSを終端して検査するカスタムプロキシが、強い保証を求める場合の手段です
• カスタムプロキシの設定:httpProxyPortを管理者が設定した場合、allowedDomainsやdeniedDomainsなどClaude Code側の制御はそのプロキシへの通信に適用されません。フィルタリングはプロキシ側の責任になります。手順はClaude Codeプロキシ設定にあります

導入の流れ

クラウド側のネットワーク制限を含めた全体設計はクラウド環境のネットワークアクセス設定にまとまっています。

導入時のつまずき

v2.1.69より前は自動遮断でなくプロンプトが出ていた

allowManagedDomainsOnlyを有効にしていても、v2.1.69より前は非許可ドメインへの接続時に承認プロンプトが出ていました。プロンプトに「Yes」と答えると意図しない通信が通る余地があったことになります。v2.1.69で、回避策のない自動遮断に修正されています。

上位の設定ソースにsandboxブロックが無いとロックごと無視される

v2.1.126より前は、複数のmanaged settingsソースを読む環境で、優先度の高いソースがsandboxブロックを持たないとallowManagedDomainsOnly(およびallowManagedReadPathsOnly)が無視される不具合がありました。MDM配布やserver-managed settingsなど複数の管理ソースを併用している組織は、どのソースにもsandboxブロックがあるかを見ておく価値があります。

Windowsのネイティブ環境ではサンドボックスが動かない

サンドボックスはmacOS・Linux・WSL2で動きます。ネイティブのWindowsではコマンドがサンドボックスなしで実行されるため、ネットワークのロックも効きません。Windowsの開発者には、WSL2上でClaude Codeを動かしてもらう運用が前提になります。

まとめ

allowManagedDomainsOnlyは、許可ドメインの出どころをmanaged settingsに固定し、リポジトリ側の設定とプロキシポートまで管理者のものにします。それでもexcludedCommandsと広い許可ドメインは残るため、通信の統制は許可リストの中身とあわせて設計する必要があります。