Coworkの許可リストが403(host_not_allowed)で拒否される原因と切り分け

「Allow network egress」を有効にしても403が出る原因は、セッションに渡る許可リストの不備、2026年9月の設定読み取りの不具合、組織管理側の設定の三つです。host_not_allowedはクラウド側、blocked-by-allowlistはローカルVM側の拒否文言で、device_bashのシェル通信も同じ許可リストの対象になります。

Coworkのネットワーク許可リストは、Settings → Capabilities → Code executionで設定します。「Allow network egress」を有効にし、Domain allowlistを「All domains」にします。それでも、外部ドメインへの通信が403 Forbiddenで拒否されることがあります。GitHub Issueでは2026年3月からこの種の報告が続きました。2026年9月10日の夜(UTC)には、動いていた設定ごと壊れるリグレッション(regression)も起きています。

このリグレッションは、同じIssueのスレッドに引用されたAnthropicの返信によると、すでに修正が展開済みです。ただし403の原因は一つではありません。症状の文言から原因を絞る順番を、報告された事例と一緒にたどります。

「All domains」でも403 blocked-by-allowlistで拒否される

Coworkの許可リスト(Domain allowlist)は、サンドボックス化されたVMがどの外部ドメインに通信してよいかを管理する設定です。代表的なモードは「Package managers only」と「All domains」の2つです。後者を選ぶと、UIには「Claude can access all domains on the internet」と表示されます。

Issue #30112は2026年3月の登録です。「All domains」を選んでいても外部ドメインへの通信が拒否される事例を報告しています。対象にはdraw.ioやraw.githubusercontent.comが含まれます。エラーは403 Forbiddenで、レスポンスヘッダーにはx-deny-reason: blocked-by-allowlistが付きます。

拒否理由の文字列は、実行環境によって違うという報告もあります。デスクトップのローカルプロキシではblocked-by-allowlist、クラウドコンテナ経由の実行ではhost_not_allowedです。Issue #93525には、同じアカウントの設定を背後に持つ2つの強制ポイントが別のヘッダー表記を返す、という実測が載っています。

• クラウドサンドボックス: x-deny-reason: host_not_allowedと、本文のHost not in allowlist: <ホスト名>
• ローカルのワークスペースVM: X-Proxy-Error: blocked-by-allowlist

Issue #30112自身も、関連する不具合として#19087・#18854・#21706を挙げています。

• Additional allowed domainsがJWTに含まれない(#19087)
• Coworkのプロキシがapi.anthropic.comまでblocked-by-allowlistで止める(#18854)
• 「All domains」設定が検証エラーを起こす(#21706)

3件のうち#19087と#18854は2026年1月、#21706も1月の登録です。許可リストまわりの報告は、2026年3月より前から続いていました。

3月の症状はセッション開始時のJWTで説明されていた

3月の報告で繰り返し指摘されたのは、セッション開始時に発行されるプロキシ用JWTです。ここに許可ホストのリストが固定で埋め込まれている、という見立てでした。Issue #30112のコメント(tylerwhardy、2026年3月4日)は、設定変更から12時間以上あとに開始した新しいセッションでもJWTをデコードし、allowed_hostsに独自ドメインが無いことを突き止めています。再起動不足では説明がつきません。

Issue #34690も、「All domains」に設定を変えても新しいセッションで独自ドメインにつながらないという同種の症状です。報告者は、強制されているリストが約205件のエントリだったと書いています。つまり「All domains」でも、固定の広いリストが効いていた形です。

2026年9月10日の夜、動いていた設定が全滅した

9月のリグレッションは、症状の出方が3月と違いました。Issue #93562によれば、2026年9月10日22時UTC(日本時間9月11日7時)ごろまでは正常に動いていました。同じIssueの報告者は、毎日回していたScheduled Tasks 18件が、9月11日以降すべて出力を止めたと書いています。

同じスレッドの別の報告者(martinchagnon)が示した設定は、「All domains」ではありません。「Package managers only」に独自ドメイン29件を加えた構成が、9月10日21時12分(UTC)の実行までは成功していました。22時12分(UTC)の実行から、毎時すべて拒否に変わっています。「All domains」の設定不良ではなく、保存済みの許可リスト全般が効かなくなったということです。

あゆみ

2026年9月のリグレッション(日付はUTC)

1. 9/10 22時ごろ動いていた通信が一斉に403へ

   Issue #93562・#93525・#34690に、21時台まで成功していた処理が22時台から403に変わったという記録があります。#93512の報告者だけは、観測の開始を9月9日午後(太平洋時間)と書いています。

2. 9/11Issueが相次いで登録される

   #93512・#93520・#93525・#93562・#93656が同じ日に登録されます。#93525は自動ラベルで「重複」に分類されましたが、報告者は重複先が示されていないと指摘しています。

3. UTC 18:40修正の展開が完了したとされる

   利用者が#93525に貼ったAnthropicの返信は、「最近の変更が原因で、一部のセッションがネットワーク設定を適用しなくなった」と説明します。保存した設定そのものは変わっておらず、設定の読み取りに問題があったとも述べています。

4. 9/11 19時ごろ利用者が回復を観測し始める

   benAndromedaとdheinig-sudoが、設定を変えずに通信が戻ったと#93525に書き込みます。18時50分ごろには、設定を切り替え直した後の診断で全APIが応答したという報告もあります。

5. 9/14一部アカウントの解消が記録される

   #34690では、9月14日16時47分(UTC)の測定でwww.google.comやexample.comが200に戻ったという報告が付きました。ただし同じ報告には、回復後はpypi.orgとregistry.npmjs.orgが403になり、それ以外は通るという逆転も書かれています。pip installが落ちる可能性があります。

返信の内容が当たっているなら、原因は3月の「JWTの焼き込み」とは別の層です。Issue #30112には、9月11日に回復した既存のタスクが再起動なしでexample.comに届いたという報告があります。許可の判定がセッション開始時に固定されず、継続的に評価されている可能性を示します。

9月の症状は、この返信だけでは片づかなかった例もあります。#30112には9月12日に、「All domains」にして新規セッションを立てても自分のドメインが拒否されるというmacOSの報告が付きました。#93525の別の報告者は、9月11日19時台に「やはり直っていない」と書いています。回復の時刻はアカウントや実行環境によって前後しており、全員が同時に直ったわけではありません。

重複ラベルのまま残るIssue

#93525は9月12日にクローズされ、#93656と#93520はOpenのまま「重複」ラベルが付いています。3月から9月までの系譜は次のとおりです。

個人アカウントでも組織のAdmin Capabilitiesでも起きる

この不具合は、特定の課金プランだけの問題ではありません。Issue #93562の報告者は個人組織のオーナーで、自分のアカウント1人だけで使っています。一方Issue #93520は、組織の管理者からの報告です。Organization settings → Capabilities → Network Accessを「Specific allowed domains」に設定していました。

どちらの設定経路でも、指定したドメイン(api.scryfall.comやwww.google.comなど)への通信が拒否されました。個人がUIから設定する場合も、組織の管理者コンソールから設定する場合も、許可リストの内容はセッションのプロキシに正しく渡っていません。

Issue #93656はTeamプランの組織からの報告です。「All domains」にしているのに、セッションには6ホスト分の固定リストだけが渡されていました。社内ドメインも拒否され、組織内の誰も設定を変えていなかったと書かれています。

クラウドセッション・ローカルVM・Scheduled Tasksで出方が違う

同じ不具合でも、どこで何が起きるかは実行環境によって違います。

通ったホストの組み合わせも、報告ごとに違います。Issue #93525の実測では、通ったのは5ホストでした。内訳はGitHub系の4つ(api.github.comなど)とapi.anthropic.comです。raw.githubusercontent.comは拒否されています。同じ報告者のローカルVMでは、通るのがapi.anthropic.comだけに絞られていました。

3月の#30112には、拒否されたホストの実例も多岐にわたって載っています。学術出版社(ncbi.nlm.nih.gov・nejm.org・nature.com)、音声・文字起こし系のAPI(api.openai.com・api.deepgram.com・api.elevenlabs.io)、GitHub CLIのインストールに使うrelease-assets.githubusercontent.comまで、許可リストの設定内容に関係なく拒否されたと報告されています。研究用途では、Web検索自体は動いてもヒットした文献の本文を取得できない、という指摘も出ています。ElevenLabsの音声エージェントをコネクタ経由でClaudeから管理する手順は、ClaudeとElevenLabsの連携にまとめています。

とくに見落としやすいのが、Scheduled Tasksの扱いです。Issue #93562の報告者は、出力が止まった18件のタスクがタスク一覧上は成功のまま並び続けていた、と書いています。通信が拒否されたという事実は、タスクの実行結果に反映されません。出力が来ないと気づくまで、失敗に気づく手段がないということです。

Claude Codeからスケジュール実行するクラウドルーティンでも、同種の報告があります。#93512のコメントでは、9月9日以降の定期実行が毎回失敗し、WebFetchがEGRESS_BLOCKEDを返しました。「All domains」へ変えた約22時間後の再実行でも変わらなかったそうです。WebSearchはAnthropic API経由で動くため、取得に失敗したルーティンが検索スニペットだけで報告を書き、ステータスはsuccessになるという指摘も付いています。

公式の説明と、許可リストの対象外になる経路

Coworkの公式アーキテクチャ解説は、サンドボックスを離れる通信の扱いを次のように説明しています。

All traffic leaving the sandbox passes through a mandatory proxy the sandbox can't reconfigure or bypass, and only allow-listed destinations are reachable.

サンドボックスを出るすべての通信は、サンドボックス自身が再設定もバイパスもできない必須プロキシを通り、許可リストに載った宛先にしか届きません。コメント欄で提案されているHTTP_PROXY環境変数によるローカルプロキシ迂回は、この設計と矛盾します。

一方で、別の公式ページ(Use Claude Cowork safely)は次のようにも明記しています。

Network egress permissions don't apply to the web fetch or web search tools or MCPs, including Claude in Chrome.

WebFetch・WebSearch、MCP経由のツール、Claude in Chrome拡張は、この許可リストの対象外です。Issue #93562のスレッドでは、ユーザーがChrome拡張機能(Claude in Chromeとみられる)でのGET操作をClaudeに依頼し、シェルのcurlが403の状況でも取得できたと報告しています。一部のセッションは「プロキシポリシーに反する」と断ってきたとも書かれています。

#93512には、Capabilities画面に「Network egress controls do not apply to web search, web fetch, or MCP connectors.」という注記が出ている、という書き込みもあります。

403が出たときの切り分けの順番

ここまでの報告を、症状の文言から原因を絞る順に並べ直します。

切り分け

Cowork許可リスト403の切り分け

1. 1

   エラー文言と通信の種類を見る

   多くの報告では、x-deny-reason: host_not_allowedはクラウド側の文言です。X-Proxy-Error: blocked-by-allowlistはローカルVM側に出ます。ただし逆の組み合わせや、ヘッダーのない403も報告されています。IMAP(ポート993)やFTP(ポート21)のようにHTTP(S)以外の通信なら、許可リストの設定では解決しません(前掲の表)。

2. 2

   Team・Enterpriseなら、管理画面のClaude Tagの設定を見る

   #93512のコメントによると、Admin settings → Claude Tag → 「All apps」のアクセスバンドルが、Capabilitiesの許可リストより優先されていました。バンドルに足したドメインはGET・HEAD・OPTIONSだけの既定値です。そのためPOSTがrequest blocked: no rule allows host ...で403になったといいます。ブロックの文言には設定の出どころが出ないので、Capabilitiesが「All domains」でも見落としやすい点です。同じスレッドには、Claude Tagを使っていなくても症状が起きていたという報告もあります。

3. 3

   実行場所をローカルに切り替えて比べる

   9月11日のスレッドには、Settings → Cowork → 「Only on this computer」へ切り替えて新しいセッションを始めたら通信できた、という報告があります。Redditの投稿を転載したもので、クラウドに移されていない古い会話なら通信できたという報告も別にあります。ただしAnthropicの返信は、デスクトップのローカル実行セッションも影響を受けたと説明しており、切り替えで直らない場合もあります。また、複数端末から続きの会話を使いたい運用には向きません。切り替え前から存在するセッションには反映されず、新規セッションから効くとも書かれています。

4. 4

   取得だけなら、許可リスト対象外のツールで代替する

   WebFetch・MCP・Claude in Chromeは先に引用した公式の記述どおり対象外です。ただしWebFetchでも拒否されたという報告があります。コネクタが渡したアップロード先へのPOSTはサンドボックスの通信になる、という指摘もあります。シェルからcurlで叩く処理は、許可リストの影響を受けます。

5. 5

   Scheduled Tasksは出力の有無で確かめる

   実行結果のファイルや通知が届いているかを確かめる手順を、タスクの流れに足しておきます。

まとめ

403の原因は、3月型のJWTの焼き込み、9月10日の設定読み取りの不具合、組織管理側(Claude Tagのアクセスバンドル)の三つに分かれて報告されています。文言とスコープで絞れば、「All domains」を何度設定し直すより早く原因に近づけます。

Anthropicの返信の引用では、9月の不具合は修正済みです。ただし#30112・#34690・#38984・#93512・#93562はOpenのままで、2026年10月1日にも#93512にコメントが付いています。今後の動きは、regression・area:networking・area:routinesのラベルで追えます。

書き込みを伴うScheduled Tasksを運用している場合は、通信が実際に届いているかを確かめる設計にしておくと、気づかない失敗を減らせます。Coworkの取り消せない操作をどう見極めるか — 実務チェックリストが挙げる事後検証の考え方がそのまま使えます。

ドメイン単位の許可リストという発想自体は、他の製品にもあります。Claude Codeのサンドボックスにあるnetwork.strictAllowlistという設定も同じ考え方です。組織のMCPサーバーを統制するManaged MCPの許可リスト管理も同様です。ただしCoworkの許可リストは、設定した内容がプロキシまで正しく渡らない点で、これらと性質が違います。