Coworkの許可リストが403で拒否される問題と回避策

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

「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です。2つの別プロキシ実装が、同じ根本原因を抱えている可能性が指摘されています。

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

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

いずれも許可リストまわりの別報告です。2026年3月の時点で、同種の報告は#30112を含めて少なくとも4系統ありました。

原因はセッション開始時に焼き込まれるJWT

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

Issue #34690も同種の症状を報告しており、「All domains」に設定を変えても、新しいセッションで独自ドメインへのアクセスが解決しないという内容です。設定とJWT生成の連携そのものが機能していません。

2026年9月11日、動いていた設定が一夜で全滅した

この不具合は3月から散発的に報告されてきました。ところが2026年9月11日には、既存の構成ごと壊れる大きなリグレッションが起きました。Issue #93562によれば、2026年9月10日22時UTC(日本時間9月11日7時)ごろまでは正常に動いていました。構成は「Package managers only」に独自ドメイン29件を加えたものです。それ以降、すべてのホストが403に変わったといいます。

同じ日にIssue #93512・#93520・#93525・#93656も相次いで登録されました。いずれも「All domains」設定が、クラウドセッションとローカルVMの両方で無視される内容です。#93525は自動ラベルで「重複」に分類されましたが、報告者自身が「重複先として名指しされたIssueは無い」と指摘しており、対象は確定していません。#93656も同様に重複としてクローズされています。複数のユーザーが独立に同じ症状へたどり着いており、このリグレッションは特定の環境だけでは起きていません。

2026年3月から9月までの系譜を時系列で並べると、次のようになります。

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

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

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

影響の範囲 — クラウドセッション・ローカルVM・Scheduled Tasks

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

拒否されたホストの実例も多岐にわたります。学術出版社(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検索自体は動いてもヒットした文献の本文を取得できない、という指摘も出ています。

とくに見落としやすいのが、Scheduled Tasksの扱いです。Issue #93562の報告者は、日次で回していた18件のタスクについて述べています。2026年9月11日以降、すべて出力を止めました。それでもタスク一覧上は成功のまま並び続けています。通信が拒否されたという事実は、タスクの実行結果に反映されません。出力が来ないと気づくまで、失敗そのものに気づく手段がないということです。

回避策になり得るもの・ならないもの

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のスレッドでは、ユーザーがClaude in ChromeでのGET操作をClaudeに依頼しています。シェルのcurlは403で拒否される状況でも、この経路では情報を取得できたと報告されています。一部のセッションは「プロキシポリシーに反する」と誤って断ってきたとも述べられています。許可リストの不具合がシェルコマンドの通信に限られている間は、この系統のツールに切り替えることが実質的な回避策になり得ます。

まとめ

Coworkの許可リストが「All domains」でも403で拒否される不具合は、2026年3月のIssue #30112から、本稿で確認できた範囲だけで10件のIssueにまたがって報告されています。2026年9月11日には、それまで動いていた設定ごと巻き込むリグレッションが重なりました。影響はクラウドセッションとローカルVMの両方、さらにScheduled Tasksが気づかないうちに失敗する範囲にまで及んでいます。

原因として指摘されているのは、セッションプロキシのJWTの扱いです。Issue #93562にはbug・area:cowork・regression・area:networking・area:routinesのラベルが付いており、2026年9月14日までのコメントにAnthropicの担当者からの原因説明は含まれていません。今後の動きはこのラベルで追いやすくなっています。

シェルからの通信が拒否される場面では、まず切り替え先を確認する価値があります。許可リストの対象外であるWebFetch・WebSearch・MCP・Claude in Chrome経由の取得です。書き込みを伴うScheduled Tasksを運用している場合は注意が要ります。Coworkの取り消せない操作をどう見極めるか — 実務チェックリストが挙げる事後検証の設計と合わせ、通信が実際に届いているかを確認する運用にしておくと、気づかないうちの失敗に気づきやすくなります。

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