ERR_INTERNET_DISCONNECTED が出るときに、まず見るところこの症状は、少なくとも今回参照した issue では 2 つの顔があります。1 つは Chrome 拡張が橋渡しに登録されず、ツール呼び出しが即座に「接続されていない」と返るケースです。もう 1 つはデスクトップアプリ側でメッセージは届くのに、受け手のセッションが処理に入らないケースです。前者は #70390、後者は #88252 に報告があります。
切り分けの最初の一歩は、単に「動かない」ではなく、どちらの現象に近いかを見分けることです。ERR_INTERNET_DISCONNECTED という文字列が見えていても、issue の内容だけでは原因は 1 つに絞れません。少なくとも #70390 では、mcp__claude-in-chrome__* 系の呼び出しがすべて即座に失敗し、switch_browser も Connect を待たずに返ってきています。報告者は「relay sees zero controllable extensions」と述べており、拡張機能が橋に見えていない状態を疑う筋書きです。
引用できる範囲では、環境はこうです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-27T08:52:26+09:00
ただし、この出力だけからは ERR_INTERNET_DISCONNECTED の再現可否は分かりません。ここで言えるのは、少なくとも筆者の検証環境は Linux で、報告の主環境である macOS とは異なる、ということまでです。
#70390 の報告では、次の点がかなり重要です。Claude Code CLI は 2.1.186、Chrome 拡張は再インストール済み、それでも接続されない。つまり「未インストール」や「古いまま」という単純な話ではなさそうです。症状としては、Browser extension is not connected が返り、switch_browser が待たずに終わる。ここはかなり特徴的です。ブラウザ側の到達性より、拡張と bridge の結びつきが崩れているように見えます。
一方で #88252 は少し性質が違います。送信側は send_message の結果として Message sent や Message queued を受け取るのに、受信側では UI にメッセージカードが表示されても、エージェントのターンが始まらない。報告では、長時間スリープをまたぐと壊れるように見えます。ここでは「届いているのに処理されない」ことが問題で、#70390 の「そもそも接続されない」とはずれがあります。
なので、読者が自分のケースを見分けるなら、次の順で見るのがよさそうです。
Browser extension is not connected を返すか。switch_browser が待機せず終わるか。現時点で、確立した解決策はこの 2 件の issue からは読み取れません。#70390 は closed ですが、本文中に解決方法は見当たりませんでした。#88252 も open のままで、コメントは「inactivity」によるクローズと再投稿の案内だけです。したがって、ここで無理に直し方を断定するより、症状の形を揃えて報告するほうが安全です。
報告するときは、少なくとも次の 3 点があると切り分けやすいです。どの tool 名で失敗したか、返ってきた文言が何か、そして待ち時間があるか即時かです。ERR_INTERNET_DISCONNECTED だけでは情報が足りません。switch_browser が待たずに返るのか、send_message は成功するのに処理されないのかで、話はかなり変わります。
今回の一次情報から言えるのはここまでです。少なくとも、ERR_INTERNET_DISCONNECTED は「ネットが完全に切れている」というより、Claude Code 側の接続経路やセッション処理がうまく噛み合っていないときに現れているように見えます。ただし、どの層が悪いかまでは、今ある情報だけでは分かりません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-27T08:52:26+09:00