sandbox.network.allowedDomainsがClaude Desktopのゲートウェイ利用で無視される

sandbox.network.allowedDomainsが無視される問題とは

sandbox.network.allowedDomainsは、サンドボックス化されたBashコマンドが接続してよいドメインを追加登録する設定キーです。カスタムゲートウェイ経由でClaude Desktopを使う一部の企業環境で、この設定を追加しても反映されない現象がGitHub issueで報告されています。報告元はanthropics/claude-code#94758で、2026-09-16に作成されています。

3p構成のClaude Desktopでは、管理者が定めるポリシーがユーザー設定より優先されると文書化されており、今回の挙動はこの仕様で説明できる可能性があります。報告者の1人は、追記が効かないのに/sandboxが正常と表示される点も挙げています。

3人のユーザーが3台のマシンでそれぞれ別のホスト(api.openai.com、pypi.org、github.com、社内CIホスト)を対象に同じ現象を再現しており、単発の環境依存ではなさそうです。

何が起きているのか

報告された環境は、deploymentMode: "3p"のエンタープライズ向けClaude Desktop(macOS、Apple Silicon、アプリ1.24012.1、内蔵Claude Code 2.1.236および2.1.270)です。ANTHROPIC_BASE_URLでOpenAI互換のカスタムゲートウェイを指定し、ANTHROPIC_AUTH_TOKENで認証しています。

この構成でサンドボックス化されたBashコマンドから外部ホストへ到達できるかを調べると、接続を許可されているのはゲートウェイのホストとapi.anthropic.comの2つだけでした。

ブロックされたホストの多くはsrtプロキシでエラーを出さずに失敗し、権限プロンプトも表示されません。別マシンではdeny network-outbound <host>:443 (user denied)という拒否ログが残ったケースもあり、拒否の見え方はマシンによって揺れています。

通常のClaude CodeではallowedDomainsはどう反映されるか

サンドボックスのdocsでは、sandbox.network.allowedDomainsは~/.claude/settings.jsonなどの設定ファイルに追加した時点でサンドボックスプロキシの許可リストに加わり、次にサンドボックス化コマンドが実行されるタイミングで有効になります。報告者はこの手順どおりに設定ファイルへ追記し、アプリを完全終了(トレイからQuit)して再起動したうえで、設定が保持されていることも確認しています。それでもapi.openai.comとpypi.orgへの到達は変わらずブロックされたままでした。

claude_desktop_config.jsonにはネットワーク関連のキーは存在せず、managed-settingsファイルも配置されていないことを、報告者は確かめています。/sandboxのUIは正常と表示する一方でプロキシは拒否を続けており、UI表示と実際の挙動が食い違っている点も2人目の報告者から挙がっています。

ネットワーク隔離では、サンドボックスの外で動くプロキシサーバーがすべての通信を仲介します。allowedDomainsにあらかじめ登録したドメインはプロンプトなしで通過し、リストにないドメインは初回接続時に承認を求めるのが既定の動作です。さらにstrictAllowlistを有効にすると、リスト外のドメインはプロンプトを出さずに拒否へ切り替わります。

今回のケースは、プロンプトもエラー表示もなく失敗する点がstrictAllowlistの挙動と似ています。通常のClaude Codeの仕様なら、allowedDomainsに追加したドメインはプロンプトなしで通るはずです。3pではmanagedポリシーが優先されるため(後述)、この食い違いは仕様どおりの可能性があります。

3pではmanagedポリシーが優先される

issueの「Expected」欄は、2つの方向を挙げています。1つは、ゲートウェイ本体とapi.anthropic.comを暗黙の許可に残したまま、ユーザー設定やmanaged設定のallowedDomainsでそこへ追加できるようにすること。もう1つは、3pモードの固定された許可リストの挙動を、管理者が上書きできる手段つきで文書化することです。

Claude Desktop on 3Pのdocsは、この固定をmanagedポリシーとしてCode側に説明しています。coworkEgressAllowedHostsなど一部の設定キーはClaude Codeのmanaged settingsに変換され、セッションにポリシーとして渡されます。ユーザー設定やプロジェクト設定より優先されます。

coworkEgressAllowedHostsは、管理者が指定したホストと推論・テレメトリ先だけに絞ったネットワークサンドボックスと、allowManagedDomainsOnlyに変換されます。未設定の場合に到達できるのは推論エンドポイントだけで、パッケージのインストールやWeb取得は403で失敗します。

allowManagedDomainsOnlyが有効だと、managed settingsのallowedDomainsだけが有効になります。つまり3pでユーザーがallowedDomainsへ足したホストが通らないことは、docsの仕様から説明がつきます。

観測された「ゲートウェイとapi.anthropic.comだけに到達できる」状態は、このdocsの記述と整合的に見えます。ただし報告環境でcoworkEgressAllowedHostsが設定されていたかは、issue本文から読み取れません。api.anthropic.comが推論・テレメトリ先に当たるかどうかも、docsからは断定できません。手がかりとして、Codeセッションのweb取得は送信前にapi.anthropic.comへドメイン確認を行い、既定ではこのホストへ到達できることが前提になっています。

別途managed-settings.jsonやOSのプロファイルを配置している端末では、Desktopが渡す値は既定で無視されます。issueの報告者はmanaged-settingsファイルは無いと書いています。3pではサーバー管理設定の層も存在しないため、Claude Code用のOSプロファイルが無ければ、Desktopのポリシーがそのまま適用される構成です。OSプロファイルの有無はissue本文に書かれていません。

Claude apps gatewayとカスタムゲートウェイは別物

このissueが指す「ゲートウェイ」は、Anthropicがclaudeバイナリに同梱するセルフホスト型のClaude apps gatewayではなく、組織がすでに運用している別のLLMゲートウェイ製品です。公式docsによると、Claude apps gatewayは各リリースに合わせて配布されるため転送ルールを保守し続ける必要がない一方、別製品のゲートウェイは新しいヘッダーやリクエスト項目が増えるたびに転送ルールを更新する側の責任になります。

ANTHROPIC_BASE_URLだけを設定してゲートウェイ資格情報を発行しない場合、モデルへのリクエストはゲートウェイ経由になっても、認証はclaude.aiのサブスクリプションログインのまま維持されます。今回のissueの環境はANTHROPIC_AUTH_TOKENとCLAUDE_CODE_HOST_AUTH_ENV_VARも設定されており、ゲートウェイ資格情報での認証に切り替わっている構成です。サブスクリプションのままの構成とゲートウェイ資格情報に切り替えた構成とで、サンドボックスの許可リストの挙動に差が出るかどうかは、issue本文からは読み取れません。

影響はどの利用形態に及ぶか

同じsandbox.network.allowedDomainsという設定でも、接続経路によって実際の影響は変わります。

issue本文は、この構成が企業向けに推奨される構成そのものなのに、開発ツール類がほぼ何にも到達できないサンドボックスになる点を影響として挙げています。ユーザーはコマンドをサンドボックスの外、つまり自分のターミナルで直接実行することで回避しており、issueでは原因が「コーポレートゲートウェイに切り替えたせいだ」と理解されがちだと書かれています。前の節で見たとおり、実際の原因は管理ポリシーの側にある可能性があります。

今できる回避策

サンドボックスのfilesystem層を無効化するsandbox.filesystem.disabledは、ネットワーク隔離自体は維持したまま書き込み制限だけを外す設定なので、今回のネットワーク到達性の問題には効きません。ネットワーク側の制御はallowedDomains・deniedDomains・strictAllowlist・allowManagedDomainsOnlyの組み合わせで決まります。

まず管理者側の経路です。3p向けdocsに沿った調整は、ユーザーの設定ファイルではなく管理側で行います。

1. coworkEgressAllowedHostsにホストを列挙する。pip・npm・社内CIなど必要なホストを入れます。*.corp.comのようなワイルドカードが使えます。*を指定するとサンドボックス自体が無効になります。ホストはネットワーク側のファイアウォールでも開けておく必要があります。:port付きのエントリは、Code側への変換ではホスト名だけとして扱われます
2. 別途managed-settings.jsonを配置している場合は重ね方を決める。その場合Claude Desktopが渡す値は既定で無視されます。parentSettingsBehavior: "merge"で重ねるか、managed-settings側にallowedDomainsを書きます。mergeにはClaude Code v2.1.133以上が必要です

allowManagedDomainsOnlyが有効な環境では、managed settingsに書いたallowedDomainsだけが有効になります。サンドボックスのdocsでも、許可リストを管理者がロックしている環境ではプロンプトが出ないため、管理者にホストの追加を頼む運用が前提です。

次に、ユーザー側の一時的な回避経路です。

1. excludedCommandsに該当コマンドを追加する。サンドボックスの外で実行するコマンドとして登録すると、そのコマンドはサンドボックスのネットワーク制限を受けずに動きます。excludedCommandsはmanaged設定でもロックできないため、開発者はいつでも項目を追記でき、サンドボックス外で動くコマンドを増やせます
2. 失敗時にサンドボックス外での再実行を承認する。allowUnsandboxedCommandsがfalseでない環境では、Claude Codeがサンドボックス外での再実行を提案してくることがあり、これを承認すればそのコマンドだけ制限を回避できます

この2つはいずれもコマンド単位の一時的な回避で、管理側の許可ホストが見直されるまでの応急処置です。

httpProxyPort/socksProxyPortによるカスタムプロキシ設定という別の経路もあります。これはコマンド単位ではなく設定全体に効く仕組みです。3pゲートウェイ構成での効果や、auto modeのコマンド単位の許可ドメイン設定との関係はissue上で検証されていないため、確立した回避経路としては数えられません。

issueが求める恒久対応は、ゲートウェイ経由でもallowedDomainsの追加分がマージされる修正です。管理者向けの上書き手段は、issueの2つ目の要望にあたるものとしてcoworkEgressAllowedHostsがdocs側にすでにあります。そのうえで、管理ポリシーが原因だと/sandboxの表示やプロンプトで分かるようになる改善も考えられます。

{
  "sandbox": {
    "network": {
      "allowedDomains": ["api.openai.com", "pypi.org"]
    }
  }
}

まとめ

sandbox.network.allowedDomainsの未反映は、ANTHROPIC_BASE_URLでサードパーティのカスタムゲートウェイに接続する3pエンタープライズ構成のClaude Desktopで確認されている現象です。3p向けdocsでは、coworkEgressAllowedHostsのようなmanagedポリシーがユーザー設定より優先されます。許可ホストの追加は管理者側の設定で行う仕様と読めます。

ずれているのは仕様そのものより見え方です。追記が効かないのに/sandboxは正常表示で、プロンプトも出ないため、ユーザーは設定ミスかゲートウェイの不具合だと受け取りやすくなります。

該当するのはあくまでカスタムゲートウェイ経由の3p構成で、ANTHROPIC_BASE_URL自体をAPIエンドポイント切り替えの手段として使う一般的な使い方(ANTHROPIC_BASE_URLでAPIエンドポイントを切り替える)とは別の論点です。ゲートウェイ経由のClaude Desktopを運用する管理者は、pip・npm・社内CIなどのホストをcoworkEgressAllowedHostsに入れる設計を先に見直す選択肢があります。そのうえで、設計が間に合わないコマンドについてexcludedCommandsの運用を考えます。

サンドボックスまわりの設定はallowedDomains以外にも、資格情報マスクに必要なsandbox.network.tlsTerminateや、Linux環境でapply-seccompが失敗するsetgroupsの問題(apply-seccompのsetgroups書き込みがLinuxで失敗する原因と対処)、unshare(CLONE_NEWUSER)が失敗するケース(unshare(CLONE_NEWUSER)がClaude Codeのサンドボックスで失敗する原因)など、環境固有のつまずきが積み重なっている領域です。ANTHROPIC_BASE_URL絡みでは、全リクエストが失敗する不具合を修正したClaude Code v2.1.276のような直近のリリースもあわせて確認しておくと状況を追いやすくなります。

issueにはコメントが付いていないため、修正されるか仕様として閉じられるかは外部からは判断できません。カスタムゲートウェイ経由の3p構成を採用している組織は、issueのウォッチと合わせて、影響を受けるコマンドの棚卸しを先に進めておくという選択肢があります。