enableWeakerNetworkIsolationはmacOSのtrustdへの経路を開く設定

sandbox.enableWeakerNetworkIsolationは、macOSのサンドボックスからシステムのTLS信頼サービスtrustd(com.apple.trustd.agent)への経路を開く設定です。既定はfalseです。gh・gcloud・terraformのようなGo製CLIをMITMプロキシ配下で動かすときだけtrueにします。信頼経路を開く代わりに、公式ドキュメントは潜在的なデータ漏出経路が生まれると明記しています。

この設定はv2.1.69(changelogの日付は2026年3月5日)で追加されました。macOS専用で、追加時の説明も「独自のMITMプロキシとhttpProxyPortを組み合わせたときにGoプログラムが証明書を検証できるようにする」というものです。

enableWeakerNetworkIsolationは何を許可する設定か

キーの場所はsandbox.enableWeakerNetworkIsolationで、型はBoolean、スコープはAny fileです。ユーザー設定・プロジェクト設定・ローカル設定・managed設定のどこからでも書けます。同じサンドボックス配下でもApple Eventsを許可するallowAppleEventsは、ユーザー・managed・CLIの設定でだけ有効で、プロジェクト設定は無視されます。この設定のスコープもAny fileですが、管理者がサンドボックスを必須にしている間は、プロジェクト設定とローカル設定のtrueが無視されます(後述)。

trueにすると、サンドボックス化されたコマンドはmacOSのシステムTLS信頼サービスであるtrustdに到達できるようになります。false(既定)のままだと、この経路は塞がれたままです。効果があるのはmacOS上でSeatbelt(macOSのサンドボックス機構)が動いているときだけです。Linux・WSL2のサンドボックスはbubblewrapという別の仕組みで、この設定の対象ではありません。

TLSエラーが出たとき、どの設定に行き着くか

この設定が必要になるのは、症状がかなり絞られた場面です。次の順に切り分けると、無関係な環境で有効化せずに済みます。

MITMプロキシ配下でGo製CLIがTLS検証に失敗する理由

既定でサンドボックスに組み込まれているプロキシは、リクエスト先のホスト名をドメイン許可リストと照合するだけです。tlsTerminateを設定しない限り、TLSトラフィックの中身は検査しません。この既定の挙動を変えて自前のTLS終端プロキシを差し込みたい組織が使うのがsandbox.network.httpProxyPortです。Claude Code自身が用意するプロキシの代わりに、組織独自のプロキシを指定できます。

公式が挙げる用途は、HTTPSトラフィックの検査、独自のフィルタリングルール、リクエストのログ取得の3つです。プロキシがTLSを復号するには自前の証明書を発行し直します。クライアント側は、その証明書を発行した独自CAを信頼しなければなりません。

httpProxyPortだけを設定した場合、SOCKSトラフィックは引き続きClaude Code組み込みのプロキシが処理します。プロキシ側でSOCKS通信も扱いたいときはsocksProxyPortも指定します。

gh・gcloud・terraformはいずれもGo製のCLIです。httpProxyPortでMITMプロキシと独自CAを使うとき、これらのツールは証明書の検証にtrustdを必要とします。既定のサンドボックスはこの経路を遮断しているため、その構成ではこれらのツールが検証に失敗します。MITMプロキシのない環境でも、Seatbelt配下で検証に失敗することがあります。

設定方法

この設定はサンドボックス機能そのものを有効化するsandbox.enabled: trueがあって初めて意味を持ちます。

{
  "sandbox": {
    "enabled": true,
    "network": {
      "httpProxyPort": 8080
    },
    "enableWeakerNetworkIsolation": true
  }
}

httpProxyPortで組織独自のプロキシを指定したうえで、enableWeakerNetworkIsolationをtrueに足す構成です。

managed設定で組織が値を固定する運用では、Boolean型のenabledやfailIfUnavailableについて、managed設定の値が使われ、開発者がローカルで書いた値は無視されると説明されています。enableWeakerNetworkIsolationは、サンドボックスのページの表に名前が挙がっています。managed設定かCLIの--settingsでallowUnsandboxedCommands: falseにしている、またはmanaged設定でallowManagedDomainsOnly: trueにしていると、サンドボックスは必須の扱い(admin-required)になります。この間、リポジトリの.claude/settings.jsonと.claude/settings.local.jsonに書いたtrueは無視され、falseは有効のままです。managed設定がこのキーを書いていなければ、各開発者の~/.claude/settings.jsonの値は使われます。この規則はv2.1.285以降のものです。各スコープの優先関係はClaude Code設定ガイドにあります。

excludedCommandsとの使い分け

TLS検証に失敗するツールへの対処は2通りあります。どちらを選ぶかは、プロキシがTLSを終端しているかどうかで決まります。

excludedCommandsは「便利機能であってセキュリティ境界ではない」と位置付けられている設定です。分離を丸ごと外す点は、ファイルシステム側の分離だけを外すsandbox.filesystem.disabledとは範囲が違います。ネットワーク分離まで外れるので、gh・gcloud・terraformを丸ごとサンドボックスの外に出したくない場合にenableWeakerNetworkIsolationが選択肢になります。

excludedCommandsが効かない呼び出しの形

各エントリはBash(...)権限ルールと同じ書式で、完全一致・docker *のようなプレフィックス・ワイルドカードパターンのいずれも書けます。

{
  "sandbox": {
    "excludedCommands": ["gh *", "gcloud *", "terraform *"]
  }
}

エントリが呼び出しの全コマンドを覆ったときだけ、その呼び出しはサンドボックスの外に出ます。v2.1.277より前は、複合コマンドの一部にだけ一致していても呼び出し全体が除外されていました。v2.1.277で「すべての部分が一致しなければならない」に直っています。

一致していても、サンドボックスに残る呼び出しの形があります。対象は、sudo・eval・xargsで始まるコマンド、呼び出しのどこかにあるcd・pushd・popd、コマンド置換やサブシェル、ifやforのような制御構文です。ファイルディスクリプタの複製(2>&1)以外のリダイレクトと、変数から決まるコマンド名も同様です。例として、docker *のエントリではcd build && docker compose upが除外されない、というものです。

gh *のエントリを入れても、cd repo && gh pr listのような呼び出しは同じ規則でサンドボックスに残ると読めます。その場合、excludedCommandsに入れたのにTLSエラーが続きます。この形で困るなら、除外の網を広げるよりenableWeakerNetworkIsolationのほうが呼び出しの書き方に左右されません。

excludedCommandsは、managed設定でもユーザーが追記できる配列です。managed設定だけで固定する仕組みはないため、managed側の一覧は狭く保つ必要があります。

enableWeakerNestedSandboxと混同しない

名前が非常に似ている設定にsandbox.enableWeakerNestedSandboxがあります。用途もOSも違うため、混同すると意図しない箇所のセキュリティを緩めることになります。後者の使いどころはenableWeakerNestedSandboxとbwrapPathの記事にあります。

設定名自体はどのOS上でも書けますが、効果が生まれるのはそれぞれの対象OS上だけです。

tlsTerminateとの違い

同じsandbox.networkの配下にあるtlsTerminateも、名前に「TLS」を含むため混同しやすい設定です。ただし対象がまったく違います。tlsTerminateは、Claude Code組み込みのプロキシ自身にTLSを終端させ、HTTPSリクエストの中身を読めるようにする実験的な設定です。maskによるクレデンシャル置換がこれを前提にしており、{}を指定するとセッションごとの一時的なCAを生成します。caCertPath・caKeyPathで自前のCAを指定することもできます。スコープはUser or managedに限られ、v2.1.199以降が必要です。

enableWeakerNetworkIsolationが想定するのは、組織がhttpProxyPortで用意した自前のMITMプロキシです。tlsTerminateはClaude Code組み込みプロキシの挙動を変える設定で、対象の層が違います。自分がどちらの層のTLS終端を設定しようとしているかを区別してから触ります。

社内プロキシへの接続そのものを通す設定(HTTPS_PROXYやNO_PROXY)は別の話です。こちらはClaude Codeプロキシ設定ガイドで扱っています。設定ファイルのenvブロックに書くとバックグラウンドエージェントにも渡り、Claude Codeはドメイン許可リストで絞ったうえで、通してよい接続を上流のプロキシへ中継します。この経路はhttpProxyPortで自前のTLS終端プロキシを差し込む構成とは別物です。サンドボックス全体の設計はClaude Codeのサンドボックス設計にあります。

strictモードやドメイン許可リストとの関係

公式のトラブルシューティングでは、サンドボックスがコマンドを止めたとき、Claudeがサンドボックス外での再実行を提案することがあると説明されています。allowUnsandboxedCommandsをfalseにすると、この逃げ道は閉じます。/sandboxのOverridesタブでは、この状態がStrict sandbox modeと表示されます。

strictモードでは、すべてのコマンドがサンドボックスの中で動くか、excludedCommandsに載っているかのどちらかです。managed設定か--settingsでallowUnsandboxedCommands: falseを指定すると、プロジェクト設定とローカル設定のexcludedCommandsは無視されます(v2.1.282)。MITMプロキシ配下でGo製CLIが止まり、excludedCommandsへ入れたくない組織では、enableWeakerNetworkIsolationが実質的な出口になります。この組み合わせは記述からの推測で、推奨構成として書かれているわけではありません。

有効化しても、ドメイン単位の制御は別の層に残ります。sandbox.network.allowedDomains・deniedDomainsが決めるのは接続先のホスト名です。この設定が開くのはtrustdへの経路で、説明もそれ以上の範囲には及んでいません。

よくある質問

Claude Code本体のTLSエラーにも効きますか

効きません。サンドボックスが隔離するのはBashのサブプロセスで、本体の通信はその外にあります。本体が独自CAで失敗するなら、ルート証明書をOSの信頼ストアに入れるか、NODE_EXTRA_CA_CERTSで追加CAのファイルを指定します。npm経由でインストールした場合、OSストアの読み取りにはNode 22.15以降が必要です。

ネイティブのWindowsでも設定できますか

設定自体は書けますが効果はありません。サンドボックスはネイティブのWindowsでは動作せず、対象はmacOS・Linux・WSL2です。Windowsのホストを含む構成では、設定の適用先をmacOSとLinuxに限るか、WSL2やコンテナの中でClaude Codeを動かします。

まとめ

MITMプロキシと独自CAを使っていないなら、excludedCommandsのほうが影響範囲は狭く済みます。enableWeakerNetworkIsolationは、httpProxyPortのMITM構成でexcludedCommandsが使えない、または効かない呼び出しの形があるときに検討する設定です。有効化するときは、trustd経由の漏出経路を受け入れられる環境かを先に確かめます。