まず切り分けたいのは、これが「本当にローカルの Claude Code セッションが止まっている」のか、「Remote Control 側の再接続や橋渡しで詰まっている」のかです。今回の症状クラスタでは、同じエラー文言でも少なくとも 2 つの筋が issue として出ています。
ひとつは、Remote Control の再接続が短時間に集中したときにホスト側がバックオフなしの再試行ループに入るという報告です。#79342 では、claude-code 2.1.199、Linux、Remote Control host mode の環境で、claude-rc@* のような常時稼働ホストが複数あり、Desktop app から worktree サブセッションを起こしている構成が説明されています。そこで観測されたのは、再接続が短時間に多発したあとに多数の RC セッションで handshake が失敗し、影響を受けたホスト側 TUI が dead socket に対して repaint/retry を延々と続ける挙動でした。issue 本文では、"Remote Control disconnected" のバナーが約 1 Hz で再描画され、自己回復しないと書かれています。
もうひとつは、最初のペアリング以外では remote-control が再接続できないという報告です。#81109 では、desktop app から local の Claude Code terminal session を操作する remote-control 機能が、ログイン直後の最初の起動ではつながるものの、その後の app restart ではつながらず、claude /logout のあとに claude /login を行っても復帰しないとされています。表示される文言として、원격 제어 연결 끊김 (Remote control connection lost)、터미널의 Claude Code 세션이 응답을 멈췄습니다. (The terminal's Claude Code session stopped responding.)、そして今回の英語エラー文がそのまま挙げられています。
ここで大事なのは、少なくとも issue ベースでは「この文言が出たら必ずログインし直せば直る」とは言えないことです。#81109 では、/logout と /login を挟んでも再接続しなかったと書かれており、単純な認証切れだけで説明できる症状ではありません。逆に、#79342 では、問題の中心は認証よりも、再接続の集中時に host 側が詰まることにあります。
筆者の環境で実際に確認できているのは、検証時の OS と Python、日時だけです。少なくともこの情報だけでは、どの再現経路に当てはまるかまでは判断できません。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-11-01T08:57:32+09:00
今のところ、手元で裏が取れている事実だけで言うなら、次の順で見るのが自然です。まず、Remote Control を使っているなら、直前に再接続が集中していないか、複数ホストや複数セッションが同時に動いていないかを確認します。#79342 の報告は、その条件で host 側が busy な再試行ループに入ることを示しています。次に、desktop app からの接続だけが落ちていて、ローカル端末側が無反応ではないなら、#81109 に近い「bridge_state が初回起動から進まない」筋を疑います。ただし、現時点で公開 issue から確認できるのは症状の一致までで、恒久的な解決策は確立していません。
確認できる範囲では、どちらの issue も closed になっていますが、本文中に有効な修正手順は示されていませんでした。したがって、このエラーが出たときに「何をすれば必ず直る」とは書けません。少なくとも、issue 報告上は再接続失敗や busy spin が関係している可能性があり、単にメッセージを再送するだけでは戻らないケースがある、というところまでです。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-11-01T08:57:32+09:00