「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自体やあなたのローカルネットワークの不調ではなく、環境側のポリシーによる意図的な遮断だと理解してください。
なぜ発生するか — Default環境のTrustedアクセスの範囲
新規にクラウド環境を作ると、既定ではDefault環境が使われます。Default環境のネットワークアクセスレベルはTrustedで、パッケージレジストリ・クラウドプロバイダーAPI・コンテナレジストリ・主要な開発ドメインという既定の許可リストにしか到達できません。社内APIや自社ドメイン、許可リストに載っていないSaaSへの通信は、Trustedのままでは必ず拒否されます。
GitHub操作とMCPコネクタの通信だけは、この許可リストとは別の経路を通ります。GitHub操作は専用のGitHubプロキシを、MCPコネクタはAnthropicのサーバーを経由する接続を使うため、他のホストが軒並みブロックされていてもこの2つだけは動き続けます。「GitHub連携もMCP接続も生きているのに、このAPIだけ403になる」という状況は、まさにこの構造から起きます。
ネットワークアクセスレベルは4段階です。
| レベル | 到達できる範囲 |
|---|---|
| None | 到達できる範囲セッションのネットワーク経由での外部通信は不可 |
| Trusted(既定) | 到達できる範囲既定の許可リスト(パッケージレジストリ・GitHub・クラウドSDK等)のみ |
| Full | 到達できる範囲任意のドメイン |
| Custom | 到達できる範囲自分で指定したドメインのリスト(既定リストとの併用も可) |
Noneでもクラウド側のAnthropic API接続自体は維持されるため、Claude本体との通信が切れるわけではありません。止まるのは、あなたのコードが叩こうとした外部APIやWebhookの通信です。
403の裏で何が起きているか — セキュリティプロキシの役割
Anthropicがホストする環境では、クラウドセッションの外向き通信はすべてHTTP/HTTPSのネットワークプロキシを経由します。このプロキシは許可リストの照合だけでなく、悪意あるリクエストからの保護・レート制限・コンテンツフィルタリング・アクセスしたホスト名のDNSレベルの監査ログという役割もあわせて持っています。TLS証明書がおかしく見える現象や、拒否時にプロキシ由来のレスポンスが返る挙動は、この構造の副作用です。
自前でインフラを持つセルフホスト環境では話が変わります。この場合、外向き通信はAnthropicのプロキシではなく、あなた自身のネットワーク境界を通って出ていきます。既定でegressを許可しない(default-deny)構成を取っているデプロイもあり、許可の管理は組織側のネットワーク設定に委ねられます。セルフホスト環境で同じエラーに当たったときは、claude.aiの環境設定だけでなく、デプロイ先のネットワーク境界の設定もあわせて確認する必要があります。
エラーを解消する手順 — Customアクセスへの切り替え
対処はシンプルです。ブロックされたドメインを環境の許可リストに追加します。
- 該当のRoutineを編集画面で開くか、クラウドセッションを開始する
- メッセージ入力欄の上にある、環境名を表示しているクラウドアイコンを選ぶ
- 対象の環境にカーソルを合わせ、表示される設定アイコンをクリックする
- 「Update cloud environment」ダイアログで、Network accessをTrustedからCustomに変更する
- Allowed domainsに、ブロックされたドメインを1行1件で追加する
- 既定の許可リストも併用したい場合は「Also include default list of common package managers」にチェックを入れる
- Save changesで保存する
以降にそのRoutineや環境から起動するセッションから、更新後の許可リストが適用されます。すでに実行中のセッションには反映されません。実行中のRoutineに変更を効かせたいなら、次回の起動を待つか、あらためて起動し直す必要があります。
Allowed domainsの入力例は次のとおりです。ワイルドカードでサブドメインをまとめて許可できます。
api.example.com
*.internal.example.com限定した許可リストの管理が煩雑なら、Network accessをFullに切り替える選択肢もあります。ただしFullは任意のドメインへの通信を許すため、意図しないデータ送信先まで開いてしまうリスクとのトレードオフになります。社内システムなど固定のドメインだけを開けたいケースでは、Customで個別に許可するほうが安全です。
ローカルCLIとの違い、Routine / Claude Tagでの見え方
このネットワークポリシーはクラウドセッションだけに適用されます。手元のマシンでclaudeコマンドを直接起動しているローカルCLIセッションは対象外で、あなたのマシンが到達できる範囲がそのまま使えます。同じ環境設定は、Claude Code on the webだけでなく、ターミナルからのclaude --cloud、Claude Tag、Routine、モバイルアプリ、Desktopアプリのクラウドセッションにも共通して適用されます。Routineのスケジュール実行をClaude Code Routines完全ガイドで組んでいる場合、外部APIを叩くステップを足すたびにこのエラーに当たりやすくなります。
一方、Remote Controlのセッションは性質が異なります。Remote Controlはウェブやモバイルの画面をあなた自身のマシン上のセッションにつなぐ機能で、通信は手元のマシンのネットワークをそのまま使います。クラウド環境のネットワークポリシーは経由しません。Claude Tagのチャンネルセッションは、個人のクラウド環境ではなく組織が管理する共有環境だけを使う点も覚えておくと切り分けが早くなります。Claude Tagでチームの共有チャンネルからClaudeを呼び出している場合、この403に当たったら組織側の共有環境の設定を管理者に確認してもらう流れになります。
この制限がある理由 — 既定でTrustedにしてある設計
クラウドセッションはサンドボックスVM上で、人が張り付いて監視していない状態のまま自律的にコマンドを実行します。既定のネットワークアクセスをTrustedに絞ってあるのは、その状態でも任意の外部ホストへ勝手にデータを送信できないようにするための安全設計です。開発でよく使うパッケージレジストリやクラウドAPIは最初から通しつつ、それ以外は明示的に許可しない限り塞いでおく発想です。
この設計のもとでは、Host not allowedのエラーは「壊れている」のではなく「まだ許可していない」だけです。頻繁に同じドメインでブロックされるなら、都度Fullへ切り替えるより、その環境のCustomリストにドメインを恒久的に足しておくほうが、次回以降の実行が安定します。
まとめ
「Host not allowed in a cloud session」は、クラウドセッションやRoutineの通信が環境のネットワークポリシーで許可されていないホストに向かったときに出るエラーです。ローカルCLIには影響しません。対処は環境の設定を開き、Network accessをCustomに変えてAllowed domainsに対象ドメインを追加するか、制約を緩めたいならFullを選ぶだけです。GitHub操作とMCPコネクタの通信は別経路のため、このエラーとは無関係に動き続けます。
よくある質問
セルフホスト環境でもこのエラーは出ますか
出ます。セルフホスト環境も含めて、環境ごとに設定されたネットワークアクセスレベルに従います。Anthropicがホストする環境か自前のセルフホスト環境かに関わらず、Trustedの既定リストに無いホストへの通信は同じように403で拒否されます。
環境設定を変更したのに、実行中のRoutineでまだブロックされます
環境の設定変更は、変更後に新しく始まるセッションから適用されます。すでに走っているセッションは、起動した時点の設定を保持したまま動き続けるため、変更を反映するには次回の実行を待つか、セッションを再度起動し直してください。
MCPサーバーへの接続だけを個別に許可したい場合はどうしますか
MCPコネクタの通信はAllowed domainsへの追加が不要です。Anthropicのサーバーを経由する専用チャネルを通るため、ネットワークポリシーの対象外だからです。反対に、使っていないMCPコネクタはセッションやRoutineの設定から外しておくと、Claudeが到達できるツールの範囲を絞り込めます。
アーカイブした環境を指定していたRoutineはどうなりますか
環境をアーカイブすると、その環境を明示的に指定していたRoutineは新しいセッションを開始できなくなります。別の環境を指定し直す必要があります。CLIのデフォルト環境として保存していた場合は、最初に使えるクラウド環境へ自動的にフォールバックします。