Claude Media
Claude CodeのBrowserペインでERR_BLOCKED_BY_CLIENTが出る原因と回避策
Claude CodeTips

Claude CodeのBrowserペインでERR_BLOCKED_BY_CLIENTが出る原因と回避策

Claude Code DesktopのBrowserペインで、ページ本体は開くのにCSSやJSだけが止まる。127.0.0.1に解決されるホスト名で起きる報告と、切り分け方・回避策をまとめます。

読了目安 約10分

Claude Code DesktopのBrowserペインで、自分のローカル環境のページを開くとHTMLだけが表示されてCSSもJavaScriptも読み込まれず、ネットワークログにnet::ERR_BLOCKED_BY_CLIENTが並ぶ。この症状は、hostsファイルやローカルDNSで127.0.0.1に向けた独自ホスト名で報告されています。http://localhostでは起きません。

GitHub issue #96508には、原因の説明も修正バージョンも付いていません。経過は#96508のスレッドで追えます。この記事では、報告されている再現条件、手元でできる切り分け、使えている回避策を順に並べます。

ERR_BLOCKED_BY_CLIENTが出るのはどんな条件か

issue #96508(Windows 11のClaude Desktopで報告)では、dev.example.testのようなホスト名をhostsファイルで127.0.0.1に向けた環境が再現条件として挙がっています。ペインでそのURLを開くと、トップレベルのナビゲーションは通ります。ところが同じURLへのfetchはTypeError: Failed to fetchで失敗し、ネットワークログには次のように出ます。

GET https://dev.example.test/            → 404 (top-level navigation, allowed)
GET https://dev.example.test/            → FAILED: net::ERR_BLOCKED_BY_CLIENT (fetch, same URL)
GET https://dev.example.test/favicon.ico → FAILED: net::ERR_BLOCKED_BY_CLIENT

同じページから公開CDN(cdn.jsdelivr.net)へのリクエストは200で通っています。つまり「サブリソースを全部止める」のではなく、「ローカルアドレスに解決されるホスト名への、ページ内からのリクエスト」が止まる挙動です。

これはissue #96508が単独で起こした話ではありません。先行するissue #86362(2026年8月13日起票、9月15日にクローズ)の再発として起票されています。#96508の冒頭には、#86362が「修正バージョンの記載なしにクローズされた」うえ、再現が続いていると書かれています。

報告されている環境

#96508のコメントと、#86362の報告を環境別に並べます。

環境ホスト名の解決方法報告されている状態
Windows 11(Claude Desktop)ホスト名の解決方法hostsファイル(*.test)、IISの443報告されている状態同一オリジンのfetchが失敗
Windows 11(Code tab)ホスト名の解決方法Local WPで.osドメイン、ローカルTLS証明書報告されている状態CSS・JS・フォントなど480件超が失敗
macOS(Apple silicon)ホスト名の解決方法同症状の再現報告報告されている状態開発に使えないとのコメント
macOSホスト名の解決方法/etc/resolver/testで*.testを解決報告されている状態9月15日の変更後、同一オリジンは通る。第2のループバックホストへの呼び出しは失敗
Linux(Ubuntu 24.04、Electron 44)ホスト名の解決方法/etc/hosts、mkcertのHTTPS報告されている状態同一オリジンのサブリソースが全滅
macOS(DDEV)ホスト名の解決方法公開DNSのワイルドカード(*.ddev.site)報告されている状態hostsファイルを使わなくても同症状

最後のDDEV報告が示すのは、hostsファイルの有無が条件ではない点です。#86362のコメントでは、*.ddev.siteが公開DNSで127.0.0.1を返すのに同じ症状が出る、と報告されています。この報告者は、ガードが「hostsファイルへの登録」でなく「解決先のアドレス」を見ているように見えると指摘しています。

Linuxの報告者は、さらに踏み込んだ切り分けも載せています。ホスト名をLAN内のプライベートIPに向けても止まり、LANのIPアドレスを直接開けば通ります。ループバックに限らず、公開風のホスト名がプライベートアドレスに解決されると止まるように見える、という整理です。

自分の環境で同じ現象か確かめる切り分け

ペインのページ上で、次の3つを順に実行します。issueの再現手順をそのまま使えます。

await fetch('/')
await fetch('/favicon.ico')
await fetch('https://cdn.jsdelivr.net/npm/jquery@3.7.1/package.json')

前の2つがFailed to fetch、3つ目が200なら、#96508と同じ型です。次に、判断の材料を表にします。

観察読み取れること
ホスト名のURLだけ失敗、localhostは成功読み取れることホスト名が条件。サーバーやTLSの不具合ではない
ページ単体のURLを直接開くと表示される読み取れることトップレベルのナビゲーションは許可されている
通常のChromeでは表示される読み取れることアプリ側の挙動で、サーバー側の問題ではない
curl -Iが200読み取れることサーバーは正常

#86362には、/main.jsをトップレベルで直接開くと表示され、同じファイルへのfetchは止まるという対比も載っています。ファイルそのものの配信や証明書が原因なら、この対比は出ません。

回避策として報告されているもの

報告の中で「動いた」とされているものを、効き方の違いとあわせて並べます。

回避策

動いたと報告されている4つの回避策

  • localhostを使う

    #96508のコメントでは、同じペインでhttp://localhost/のサブリソースは200で読み込めたと報告されています。報告で通ったのはhttp://localhostと127.0.0.1です。*.localhostはdocsでは確認プロンプトなしで開くアドレスに含まれますが、このエラーを避けられるかという報告は見当たりません。

  • 127.0.0.1を直接指定

    #86362のコメントでは、http://127.0.0.1:8000で全サブリソースが200になったとされています。ただし実ホスト名とHTTPSを失う代償があります。

  • 公開トンネルを経由

    cloudflaredなどでローカルサーバーを公開すると、公開IPのホスト名になって通ったという報告があります。HTTPSやホスト名に依存する挙動は保てます。

  • Claude in Chromeで開く

    同じURLが通常のChromeでは問題なく読み込めるため、Claude in Chrome拡張機能で操作する選択肢があります。ペインの要素選択ツールは使えません。

launch.jsonのurlで逃げられるのは条件付き

.claude/launch.jsonのurlで開くアドレスを指定する方法は、公式docsのConfigure preview serversの節にあります。docsでは、localhost・任意の*.localhost・127.0.0.1・::1は確認なしで直接開く扱いです。それ以外のアドレスは、初回に許可を求めるプロンプトが出ます。

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "my-app",
      "url": "https://app.localhost:3000"
    }
  ]
}

commandを書かずurlだけにすると、すでに動いているサーバーにプレビューを接続します。ただしdocsの「直接開く」は許可プロンプトの扱いを指すもので、app.localhostのようなホスト名でERR_BLOCKED_BY_CLIENTが出なくなるかは、報告がなく未確認です。*.localhostも127.0.0.1に解決されるため、同じ止まり方をする可能性があります。試すなら、先に切り分けの3行を流して確かめてください。

一方、実ドメインと同じCookieドメインが要る環境では使えません。Linuxの報告者は、APIゲートウェイのセッションCookieが同一サイトのHTTPSオリジンからしか送られないため、実ドメイン配下のhostsエイリアスが必要だと書いています。

#96508のコメントには、launch.jsonに"url": "https://mysite.os"と書いてattach modeでpreview_startを使っても、サブリソースは止まったままだったという書き込みがあります。docsが確認なしで直接開くと列挙しているのはlocalhost・*.localhost・127.0.0.1・::1だけです。カスタムドメインのurlで救われるとは言えません。

許可済みサイトに入れても効かない理由

ペインのAllowed sitesにオリジンを追加すると、claude_desktop_config.jsonにlaunchPreviewAllowedOriginsなど複数のキーが書かれます。Linuxでは、これを追加し、さらにlaunchPreviewPrivateNetworkTrustedOriginsを手で設定してアプリを完全に再起動しても、症状は変わらなかったそうです。

macOSの報告では、別の形で効かない例が出ています。2つのオリジン(app.とapi.)を許可リストに入れた環境で、app.ページ自身のリソースは9月15日の変更後に通るようになりました。しかしapp.からapi.へのfetchはERR_BLOCKED_BY_CLIENTのままです。api.のURLを単体で開くと200で表示されます。このためOAuthコールバックでCookieは設定されるのに、SPAからのユーザー取得だけが止まり、ログインループになったとのことです。

この報告から読み取れる範囲は次のとおりです。

  • 許可リストが効くのは、ページ自身のオリジンのみに見える
  • 許可リストに入れた別のオリジンへの呼び出しは、効かない場合がある
  • Linuxでは、同一オリジンのリソースですら許可リストが効いていない

OS別に挙動が違う点は、症状が一種類ではないことを示しています。

経緯と、いま追える場所

流れを時系列に置くと、次のようになります。

あゆみ

#86362から#96508までの流れ

  1. 2026-08-13#86362が起票される

    8月13日を境に、hostsで解決する開発用ドメインが急に止まるようになったと報告されました。

  2. 2026-09-15#86362がクローズされる

    修正バージョンのリンクはありません。macOSの報告者は、この日以降に同一オリジンが通るようになったと書いています。

  3. 2026-09-23#96508が起票される

    Windows 11のClaude Desktop(UAはClaude/2.7032.0)で再現。以降、macOS・Linuxの報告が続きます。

  4. 2026-10-12Linuxの報告が加わる

    Ubuntu 24.04(Electron 44)で、同一オリジンのサブリソースが全滅するとの書き込みがあります。

#96508には、原因の説明も修正バージョンの案内も付いていません。症状が自分の環境と同じなら、環境の情報(OS、アプリのバージョン、ホスト名の解決方法)を#96508に足すのが、直接の窓口です。

開発フローに組み込むなら

Browserペインでの自動検証(auto-verify)に頼る開発フローでは、検証の失敗がサーバー側の不具合に見えやすい点に注意が必要です。ページ本体は200で開くので、画面が真っ白でもサーバーのログにエラーは出ません。#86362では、スクリーンショットやread_pageを使った検証ループが静かに壊れ、ネットワークログを見ないと診断できなかったとされています。

症状が出たら、まずネットワークログでERR_BLOCKED_BY_CLIENTの有無を見るのが近道です。Browserペイン自体の開き方や承認カードの扱いはClaude Code Desktopの内蔵ブラウザの使い方に、プレビュー設定の全体はClaude Code Desktopアプリプレビューの解説にあります。ペインに頼らず手元のChromeを動かしたいときは、Kapture MCPでClaude Codeから手元のChromeを操作する手順が代替になります。

まとめ

ERR_BLOCKED_BY_CLIENTは、サーバーや証明書の問題ではなく、Browserペイン側が「ローカルアドレスに解決されるホスト名」へのサブリソースを止める挙動として報告されています。条件はhostsファイルに限らず、公開DNSやローカルDNSでも出ます。

報告で通ったのはhttp://localhostと127.0.0.1です。*.localhostは、このエラーを避けられるかの報告がありません。実ドメインが必須なら、トンネルかClaude in Chromeに逃がすことになります。許可リストへの追加は、報告のある環境では効いていません。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →