「Host not allowed in a cloud session」の意味と対処 — Claude Code
クラウドセッションやRoutineが特定ホストへの通信を403で拒否するエラーの原因と、ネットワークアクセス設定での対処を解説します。
クラウドセッションやRoutineの実行中に外部への通信がブロックされると、HTTP 403が返ります。そのヘッダーにx-deny-reason: host_not_allowedが付いているものが「Host not allowed in a cloud session」です。原因はクライアント側のネットワーク不調ではなく、実行環境のネットワークポリシーが未許可のホストへの接続を止めていることにあります。対処は環境設定でアクセスレベルをCustomに変え、必要なドメインを許可リストに追加するだけです。
「Host not allowed in a cloud session」とは何のエラーか
クラウドセッションやRoutineは、あなたの手元のマシンではなくサンドボックス化されたVM上で動きます。そのVMからの通信は、環境ごとに設定された許可リスト(allowlist)を通過するプロキシ経由でのみ外へ出られます。リストに無いホストへ接続しようとすると、プロキシが403で応答を返し、拒否理由がx-deny-reason: host_not_allowedとして付きます。
このとき、接続先の証明書と一致しないTLS証明書が見えることもあります。これは攻撃や設定ミスではありません。プロキシが接続先の代わりに応答を返す仕組み上、証明書もプロキシのものになるためです。Claude Code自体やローカルネットワークの不調ではなく、環境側のポリシーによる意図的な遮断です。
403のメッセージで原因を切り分ける
クラウドセッションの403は、host_not_allowedだけではありません。GitHub向けの通信は別のプロキシを通るので、同じ403でも直す場所が変わります。
| 画面・ログの文言 | 止めているもの | 直す場所 |
|---|---|---|
403 + x-deny-reason: host_not_allowed | 止めているもの環境のネットワーク許可リスト | 直す場所環境のNetwork access(本記事の手順) |
403 + This GraphQL query is not enabled for this session | 止めているものGitHubプロキシのGraphQL制限 | 直す場所REST(gh api repos/{owner}/{repo}/...)に切り替える |
| GitHubのリリースアセットのダウンロードが403 | 止めているものGitHubプロキシのリポジトリ範囲 | 直す場所セッションに添付したリポジトリ以外は取得できない |
proxy refused the connection: HTTP 407 / 403 | 止めているもの手元のHTTPS_PROXYに指定したプロキシ | 直す場所ローカルCLIのプロキシ設定(クラウドセッションの話ではない) |
GraphQLの403は、GH_TOKENを自分で設定しても変わりません。GitHubプロキシは、プルリクエスト作業用に固定された一部のGraphQL操作しか通さないからです。Projects v2のようにGraphQLにしかないAPIも、このプロキシ経由では呼べません。
リリースアセットの403は、実際のつまずきとして報告されています。GitHubのIssue #78330に、クラウドセッション内で403になる例が複数挙がっています。GitHub Releasesからビルド済みバイナリを取得するツールが典型で、Gradleのディストリビューション取得もその一つです。アーカイブ取得(api.github.com/repos/<owner>/<repo>/zipball/<ref>など)も、セッションに添付していないリポジトリでは403になると報告されています。ダウンロードがリリースアセット用のホストへリダイレクトされる点も指摘されています。ネットワークアクセスをFullにしても、この経路はGitHubプロキシ側の制限なので変わりません。
なぜ発生するか — Default環境のTrustedアクセスの範囲
環境を作らずに始めると、既定ではDefault環境が使われます。Default環境のネットワークアクセスレベルはTrustedで、到達できるのは既定の許可リストだけです。許可リストには、パッケージレジストリ・クラウドプロバイダーAPI・コンテナレジストリ・主要な開発ドメインが入っています。社内APIや自社ドメイン、許可リストに載っていないSaaSへの通信は、Trustedのままでは拒否されます。
ネットワークアクセスレベルは4段階です。
| レベル | 到達できる範囲 |
|---|---|
| None | 到達できる範囲セッションのネットワーク経由での外部通信は不可 |
| Trusted(既定) | 到達できる範囲既定の許可リスト(パッケージレジストリ・GitHub・クラウドSDK等)のみ |
| Full | 到達できる範囲任意のドメイン |
| Custom | 到達できる範囲自分で指定したドメインのリスト(既定リストとの併用も可) |
どのレベルでも、許可リストを通らずに外へ出られる経路が4つあります。
許可リストの外を通る4つの経路
GitHub
専用のGitHubプロキシを通ります。Noneでも使えます。
MCPコネクタ
有効にしたコネクタの通信は、Anthropicのサーバーを経由します。Allowed domainsへの追加は不要です。
APIクレデンシャル
環境に登録したAPIキーの宛先ホストは、アクセスレベルに関係なく到達できます。ただしAnthropic APIや主要パッケージレジストリなど、キーを付与しない宛先があります。
Anthropic API
Claude Code自身のリクエストは、Noneでも通ります。Claude本体との通信が切れるわけではありません。
「GitHub連携もMCP接続も生きているのに、このAPIだけ403になる」という状況は、この構造から起きます。止まるのは、あなたのコードが叩こうとした外部APIやWebhookの通信です。
403の裏で何が起きているか — セキュリティプロキシの役割
Anthropicがホストする環境では、クラウドセッションの外向き通信はすべてHTTP/HTTPSのネットワークプロキシを経由します。このプロキシは許可リストの照合だけでなく、悪意あるリクエストからの保護・レート制限・コンテンツフィルタリング・アクセスしたホスト名のDNSレベルの監査ログという役割もあわせて持っています。TLS証明書がおかしく見える現象は、この構造の副作用です。
自前でインフラを持つセルフホスト環境では話が変わります。外向き通信はAnthropicのプロキシではなく、あなた自身のネットワーク境界を通って出ていきます。公式のデプロイ手順は、このネットワーク境界でのdefault-deny egress(既定で外向き通信を許可しない構成)を、すべての環境に適用するよう求めています。
したがって、セルフホスト環境でホストに届かないときは、claude.aiの環境設定ではなく、runnerのコンテナが載っているネットワークの設定を見ることになります。
エラーを解消する手順 — Customアクセスへの切り替え
対処は、ブロックされたドメインを環境の許可リストに追加することです。自分で作った環境なら、次の流れで変更できます。
許可リストにドメインを追加する
- 1
環境の編集画面を開く
Routineなら編集画面から、クラウドセッションならメッセージ入力欄の上にある、環境名を表示したクラウドアイコンから開きます。対象の環境にカーソルを合わせ、表示される設定アイコンを選びます。
- 2
Network accessをCustomに変える
「Edit cloud environment」ダイアログで、Network accessをTrustedからCustomに変更します。
- 3
Allowed domainsに1行1件で追加する
ブロックされたドメインを書き込みます。ワイルドカードの
*.で、サブドメインをまとめて許可できます。 - 4
既定リストの併用を決めて保存する
「Also include default list of common package managers」にチェックを入れると、既定の許可リストも併用できます。保存は「Save changes」です。
Allowed domainsの入力例は次のとおりです。
api.example.com
*.internal.example.comチェックボックスの扱いには注意が要ります。外したままCustomにすると、許可されるのは自分で書いたドメインだけです。npm installやpip installが通っていた環境でも、レジストリのホストを書かなければ止まります。
組織の共有環境は、一般メンバーの画面では読み取り専用です。変更はOwnerが、管理設定の「Cloud environments」ページから行います。組織全体で許可リストを配る仕組みや、server-managed settingsでドメインを足す手段は、環境ごとの許可リストにはありません。チームで同じリストを使いたいときは、OwnerがCustomの共有環境を1つ作ります。
限定した許可リストの管理が煩雑なら、Network accessをFullに切り替える選択肢もあります。ただしFullは任意のドメインへの通信を許すため、意図しないデータ送信先まで開いてしまうリスクとのトレードオフになります。社内システムなど固定のドメインだけを開けたいなら、Customが向いています。
変更はいつ反映されるか
保存後の次の実行は、新しい許可リストを使います。Anthropicがホストする環境では、開いたままのセッションも約1分以内に新しい設定に従うので、セッションを作り直す必要はありません。対象は許可リストを通るリクエストです。
約1分たっても403が続くときは、保存したのがFullやCustomではなく、いつの間にかTrustedのままという可能性を先に疑ってください。GitHubのIssue #94506には、「Fullに設定したのに403が続く」という報告がありました。実際はTrustedのままだったと投稿者が訂正し、クローズされています。
ローカルCLIとの違い、Routine / Claude Tagでの見え方
このネットワークポリシーはクラウドセッションだけに適用されます。手元でclaudeを直接起動したローカルCLIセッションは対象外で、あなたのマシンが到達できる範囲がそのまま使えます。
同じ環境設定は、ブラウザ、モバイルアプリ、Desktopアプリ、Routine、Claude Tag、そしてターミナルから作るクラウドセッションに共通して適用されます。ターミナルからはclaude --cloudを使います。v2.1.287のclaude --helpでは、次のように表示されます。
--cloud [description|session_id|url] Create a cloud session with the givenRoutineのスケジュール実行をClaude Code Routines完全ガイドで組んでいる場合は注意が要ります。外部APIを叩くステップを足すたびに、このエラーに当たりやすくなります。
一方、Remote Controlのセッションは性質が異なります。Remote Controlはウェブやモバイルの画面をあなた自身のマシン上のセッションにつなぐ機能で、通信は手元のマシンのネットワークをそのまま使います。クラウド環境のネットワークポリシーは経由しません。
Claude Tagのチャンネルセッションは、個人のクラウド環境ではなく、組織の共有環境かセルフホスト環境だけを使います。Claude Tagでチームの共有チャンネルからClaudeを呼び出している場合、この403に当たったら見るのは共有環境の設定です。変更はOwnerに依頼します。
既定のTrustedが抑えているものと、恒久対応の考え方
クラウドセッションはサンドボックスVM上で、人が張り付いて監視していない状態のまま自律的にコマンドを実行します。既定のネットワークアクセスをTrustedに絞ってあるため、許可リスト外のホストへ勝手にデータを送信することは抑えられます。
この設計のもとでは、Host not allowedは「壊れている」のではなく「まだ許可していない」だけです。同じドメインで何度もブロックされるなら、都度Fullへ切り替えるより、その環境のCustomリストにドメインを恒久的に足しておくほうが、次回以降の実行が安定します。
APIキーが必要な外部サービスなら、ProとMaxでは、キーをAPIクレデンシャルとして環境に登録する方法もあります。キーはClaudeにもセッションの環境変数にも見えません。環境変数に書いた値は、その環境を使う人なら誰でも読めます。
まとめ
直す場所は、ヘッダーを見て決めます。host_not_allowedで自分の環境なら、CustomにしてAllowed domainsへ足します。組織の共有環境やClaude TagのときはOwnerに依頼し、セルフホストなら自前のネットワーク境界を見ます。
GraphQLやリリースアセットの403はGitHubプロキシの範囲なので、Fullにしても変わりません。RESTへ切り替えるか、対象のリポジトリをセッションに添付します。