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

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

カスタムゲートウェイ経由のClaude Desktopでsandbox.network.allowedDomainsが反映されない不具合を、公式docsの仕様と突き合わせます。

読了目安 約8分

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

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

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つだけでした。

接続先結果
設定済みゲートウェイホスト結果302(到達可)
api.anthropic.com結果404(到達可)
api.openai.com結果000(到達不可)
pypi.org結果000(到達不可)
github.com結果000(到達不可)
社内CIホスト結果000(到達不可)

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

allowedDomainsは本来どう反映されるはずか

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

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

公式docsが説明するネットワーク隔離の仕組みでは、サンドボックスの外で動くプロキシサーバーがすべての通信を仲介します。allowedDomainsにあらかじめ登録したドメインはプロンプトなしで通過し、リストにないドメインは初回接続時に承認を求めるのが既定の動作です。さらにstrictAllowlistを有効にすると、リスト外のドメインはプロンプトを出さずに拒否へ切り替わります。今回のケースでは拒否こそされているものの、プロンプトもエラー表示もなく失敗する点がstrictAllowlistの挙動と似ていて、しかもallowedDomainsに追加したドメインまで拒否対象に含まれてしまっている点が本来の仕様と食い違っています。

なぜゲートウェイ経由だと無視されると考えられるか

issueの「Expected」欄では、ゲートウェイ本体とapi.anthropic.comが暗黙に許可された状態を維持しつつ、allowedDomainsがその上に追加で反映される挙動を求めています。裏を返せば、現状の3pゲートウェイ構成ではサンドボックスの許可リストがゲートウェイ検証用の2ホストに固定され、ユーザー設定側のallowedDomainsをマージしていないと読めます。

公式docsはstrictAllowlistやallowManagedDomainsOnlyのようにmanaged設定側だけを正とするロック機構は説明していますが、3pデプロイ時にゲートウェイ由来のホストだけを固定してallowedDomainsを無視する仕様は、少なくとも本記事で確認した範囲のdocsには記載がありません。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という設定でも、接続経路によって実際の影響は変わります。

利用形態影響
直接api.anthropic.comに接続する個人利用影響このissueの報告対象外
Claude apps gateway(Anthropic自前のセルフホスト型)影響未確認。issueは3pのカスタムゲートウェイでの報告に限られる
サードパーティ製カスタムゲートウェイ経由の3pエンタープライズ構成影響明確な影響あり。pip/npmインストール、HTTPS経由のgit、社内CI、Anthropic以外のAPIへの到達が軒並みブロックされる
httpProxyPort/socksProxyPortでカスタムプロキシを設定している環境影響公式docsに設定項目自体はあるが、3pゲートウェイ構成での効果はissue上で検証されていない

issue本文は、この構成がAnthropicが企業向けに推奨する構成そのものであるにもかかわらず、開発ツール類がほぼ何にも到達できないサンドボックスになってしまう点を影響として挙げています。ユーザーはコマンドをサンドボックスの外、つまり自分のターミナルで直接実行することで回避しており、その原因を誤って「コーポレートゲートウェイに切り替えたせいだ」と誤解しているケースもあると報告されています。

今できる回避策

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

公式docsが示す一般的な回避経路は次の2つです。

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

1と2はいずれもコマンド単位の一時的な回避であり、allowedDomainsが正しくマージされるようになるまでの応急処置です。

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

恒久対応としては、issueが求めているとおりゲートウェイ経由でもallowedDomainsの追加分がマージされる修正か、3pデプロイのピン留め挙動そのものを公式docsに明記する対応のいずれかが必要になります。

再現手順の設定ファイル例(issue本文より)
{
  "sandbox": {
    "network": {
      "allowedDomains": ["api.openai.com", "pypi.org"]
    }
  }
}

~/.claude/settings.jsonにこの内容を追記し、アプリを完全終了・再起動してallowedDomainsが反映されているかを確認する、というのがissue報告者の再現手順です。

まとめ

sandbox.network.allowedDomainsの未反映は、ANTHROPIC_BASE_URLでサードパーティのカスタムゲートウェイに接続する3pエンタープライズ構成のClaude Desktopで確認されている現象です。

該当するのはあくまでカスタムゲートウェイ経由の3p構成で、ANTHROPIC_BASE_URL自体をAPIエンドポイント切り替えの手段として使う一般的な使い方(ANTHROPIC_BASE_URLでAPIエンドポイントを切り替える)とは別の論点です。エンタープライズでゲートウェイ経由のClaude Desktopを運用しているチームは、pip・npm・社内CIなどへの到達性が必要なサンドボックス化コマンドがある場合、この制約を踏まえて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のウォッチと合わせて、影響を受けるコマンドの棚卸しを先に進めておくという選択肢があります。

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

関連する記事

Claude Code をもっと見る →