enableWeakerNetworkIsolationはmacOSのtrustdへの経路を開く設定
sandbox.enableWeakerNetworkIsolationは、MITMプロキシ配下でgh・gcloud・terraformのTLS検証を通すためmacOSのtrustdへの経路を開く設定です。
sandbox.enableWeakerNetworkIsolationは、macOSのサンドボックスからシステムのTLS信頼サービスtrustd(com.apple.trustd.agent)への経路を開く設定です。既定はfalseです。gh・gcloud・terraformのようなGo製CLIをMITMプロキシ配下で動かすときだけtrueにします。信頼経路を開く代わりに、公式ドキュメントは潜在的なデータ漏出経路が生まれると明記しています。
enableWeakerNetworkIsolationは何を許可する設定か
キーの場所はsandbox.enableWeakerNetworkIsolationで、型はBoolean、スコープはAny fileです。ユーザー設定・プロジェクト設定・ローカル設定・managed設定のどこからでも書けます。同じサンドボックス配下でも、Apple Eventsを許可するallowAppleEventsはユーザー設定かmanaged設定に書ける範囲が限られていますが、この設定にそうした制限はありません。
trueにすると、サンドボックス化されたコマンドはmacOSのシステムTLS信頼サービスであるtrustdに到達できるようになります。false(既定)のままだと、この経路は塞がれたままです。効果があるのはmacOS上でSeatbelt(macOSのサンドボックス機構)が動いているときだけです。Linux・WSL2はbubblewrapという別の仕組みでサンドボックスを実装しており、trustdという概念自体が存在しません。
MITMプロキシ配下でGo製CLIがTLS検証に失敗する理由
既定でサンドボックスに組み込まれているプロキシは、リクエスト先のホスト名をドメイン許可リストと照合するだけで、tlsTerminateを設定しない限りTLSトラフィックの中身までは検査しません。この既定の挙動を変えて自前のTLS終端プロキシを差し込みたい組織が使うのがsandbox.network.httpProxyPortです。Claude Code自身が用意するプロキシの代わりに組織独自のプロキシを指定する設定です。組織がこの構成を組む目的は、HTTPSトラフィックを復号して検査する、独自のフィルタリングルールを適用する、すべてのリクエストをログに残す、既存のセキュリティ基盤と統合する、の4つに整理できます。いずれの目的でも、プロキシがTLSを復号して検査するには自前の証明書を発行し直し、クライアント側にその証明書を発行した独自CAを信頼させる必要があります。
httpProxyPortだけを設定した場合、SOCKSトラフィックは引き続きClaude Code組み込みのプロキシが処理します。プロキシ側でSOCKS通信も扱いたいときはsocksProxyPortも合わせて指定します。片方だけ設定しても、もう一方の通信は組み込みプロキシが担当する仕組みです。
gh・gcloud・terraformはいずれもGo製のCLIです。公式ドキュメントは、これらのツールが証明書を検証する際にtrustdを必要とすると説明しています。既定のサンドボックスはこの経路を遮断しているため、httpProxyPortでMITMプロキシと独自CAを組み合わせた環境では、これらのツールだけがTLS検証に失敗します。Seatbelt配下でのTLS検証失敗という症状は、サンドボックスのトラブルシューティング項目としても個別に挙げられています。
失敗のタイミングにも特徴があります。ツール自体は起動し、プロキシへの接続も一見成立しますが、証明書チェーンをたどれずにハンドシェイクの段階で止まります。エラーメッセージはツールごとに異なりますが、いずれもTLS証明書の検証エラーとして現れます。
設定方法
この設定はサンドボックス機能そのものを有効化するsandbox.enabled: trueがあって初めて意味を持ちます。
{
"sandbox": {
"enabled": true,
"network": {
"httpProxyPort": 8080
},
"enableWeakerNetworkIsolation": true
}
}httpProxyPortで組織独自のプロキシを指定したうえで、enableWeakerNetworkIsolationをtrueに足す構成です。MITMプロキシを使っていないなら、この設定を有効にする理由はありません。公式ドキュメントは、その場合は失敗するツールをexcludedCommandsに列挙してサンドボックスの外で実行するよう案内しています。
Boolean型のサンドボックス設定は、managed設定で値が決まっている場合はその値が優先され、ユーザー・プロジェクト・ローカル設定からの上書きは無視されます。組織がmanaged設定でenableWeakerNetworkIsolationを固定している環境では、開発者が自分の設定ファイルに書いても反映されません。
excludedCommandsとの使い分け
TLS検証に失敗するツールへの対処は2通りあります。どちらを選ぶかは、プロキシがTLSを終端しているかどうかで決まります。
| 状況 | 対処 | 代償 |
|---|---|---|
| MITMプロキシを使っていない | 対処失敗するツールをexcludedCommandsに列挙する | 代償そのコマンドはサンドボックスの外で実行され、ファイルシステム分離とネットワーク分離の両方を失う |
httpProxyPortでMITMプロキシ・独自CAを使っている | 対処enableWeakerNetworkIsolationをtrueにする | 代償サンドボックス自体は維持されるが、trustd経由の漏出経路が開く |
excludedCommandsは公式ドキュメントが「便利機能であってセキュリティ境界ではない」と位置付けている設定です。指定したコマンドはファイルシステムもネットワークも一切分離されずに実行されます。gh・gcloud・terraformを丸ごとサンドボックスの外に出したくない場合に、enableWeakerNetworkIsolationが選択肢になります。
excludedCommandsの各エントリはBash(...)権限ルールと同じ書式で、完全一致・docker *のようなプレフィックス・ワイルドカードパターンのいずれも書けます。複合コマンドの一部がエントリに一致すると、コマンド全体がサンドボックスの外で実行されます。
{
"sandbox": {
"excludedCommands": ["gh *", "gcloud *", "terraform *"]
}
}enableWeakerNestedSandboxと混同しない
名前が非常に似ている設定にsandbox.enableWeakerNestedSandboxがあります。用途もOSも違うため、混同すると意図しない箇所のセキュリティを緩めることになります。
| 設定 | 対象OS | 解決する問題 | 代償 |
|---|---|---|---|
enableWeakerNetworkIsolation | 対象OSmacOS | 解決する問題MITMプロキシ配下でGo製CLIのTLS検証が失敗する | 代償trustd経由のデータ漏出経路 |
enableWeakerNestedSandbox | 対象OSLinux・WSL2 | 解決する問題特権のないDockerコンテナ内でbubblewrapが新しい/procをマウントできない | 代償コンテナの既存/procをbind mountするため、フレッシュなマウントなら隠れるはずのプロセス情報が露出する |
前者はmacOSのSeatbelt、後者はLinux・WSL2のbubblewrapという別々のサンドボックス実装に対応しています。設定名自体はどの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」を扱う設定という共通点だけで名前が似て見えるので、自分がどちらの層のTLS終端を設定しようとしているかを区別してから触ります。
よくある質問
MITMプロキシを使っていない場合、enableWeakerNetworkIsolationを有効にする意味はありますか
薄いです。プロキシが独自CAでTLSを終端していない限り、Go製CLIは通常のCA検証で通ります。有効化は常にtrustdへの経路を開く代償を伴うため、実際にMITMプロキシと独自CAを使っている環境に限定します。
gh・gcloud・terraform以外のツールにも効果がありますか
公式ドキュメントが名指ししているのはこの3つです。macOS上でシステムのTLS信頼ストアを経由して証明書を検証するGo製バイナリであれば同様の制約に当てはまり得ますが、挙動は個々のツールのTLS実装に依存するため、公式に確認できていないツールについては実機で検証してから判断します。
ネイティブのWindowsでも設定できますか
設定自体は書けますが効果はありません。サンドボックスはネイティブのWindowsでは動作せず、macOS・Linux・WSL2だけが対象です。Windows環境を含む場合は、対象ホストをWSL2かコンテナ内で動かす構成にする必要があります。
有効化したあとも、ドメインの許可リストは効きますか
効きます。enableWeakerNetworkIsolationが開くのはtrustdという証明書検証サービスへの経路だけで、sandbox.network.allowedDomains・deniedDomainsによるドメイン単位の制御とは別の層です。この設定を有効にしても、サンドボックス化されたコマンドが到達できるドメインの範囲そのものは変わりません。
NODE_TLS_REJECT_UNAUTHORIZED=0でも同じことができますか
できません。NODE_TLS_REJECT_UNAUTHORIZED=0はNode.jsプロセスであるClaude Code自身のTLS検証を丸ごと無効化する設定で、公式ドキュメントも明示的に避けるよう案内しています。enableWeakerNetworkIsolationはNode.jsのTLS検証には関与せず、Go製CLIがtrustdという既存の検証経路にアクセスできるようにするだけです。検証そのものを無効化するのではなく、検証経路への到達性を開く点が違います。
まとめ
sandbox.enableWeakerNetworkIsolationは、httpProxyPortでMITMプロキシと独自CAを組み合わせた環境に限って、gh・gcloud・terraformのTLS検証を通すための設定です。MITMプロキシを使っていないならexcludedCommandsで個別のツールをサンドボックス外に出すほうが影響範囲が狭く、有効化はtrustd経由の漏出経路という代償と引き換えになります。名前の似たenableWeakerNestedSandboxはLinux・WSL2向けの別設定なので、対象OSと解決する問題を確認してから設定します。サンドボックス全体の設計はClaude Codeのサンドボックス設計、ファイルシステム分離だけを外す設定はsandbox.filesystem.disabledはファイルシステム分離だけ外す設定、Claude Code自身の通信を通す社内プロキシ設定はClaude Codeプロキシ設定ガイド、settings.jsonの全体像はClaude Code設定ガイドにまとめています。