この症状は、少なくとも報告上は「一度つながったはずの Remote Control が、再接続で失敗する」かたちで出ています。該当する issue は #95609 と #87720 です。どちらも、Remote Control failed to connect: Remote Control connect timed out で止まる、あるいは connecting のまま進まない、という流れが書かれています。
まず切り分けたいのは、「そのセッションだけがおかしいのか」「Remote Control 自体が環境全体で不安定なのか」です。#95609 では、同じアカウントでも別のセッションは claude.ai/code の Web では見えており、モバイル側だけ 連結 해제됨 相当の状態に見えていました。つまり、アカウント全体の認証不能というより、特定セッションの再接続に失敗しているように見えます。#87720 でも、モバイルアプリ側にはそのセッションの transcript が残っていて、接続の履歴自体はあるのに、同じセッションへの /remote-control 再実行で失敗しています。
報告されている失敗の見え方は、だいたい次のどれかです。
Remote Control failed to connect: Remote Control connect timed out
connecting
Disconnected · Remote control
#87720 の本文には、以前はモバイルアプリに接続できていたセッションが、後から再度 attach しようとするとタイムアウトする、とあります。さらに、同じマシンから claude remote-control --spawn same-dir は接続できたと書かれているので、少なくともその報告では「マシン全体が壊れている」とは言えませんでした。ここは重要で、セッション単位の問題か、再接続の経路だけの問題かを見分ける材料になります。
コメント側の断片では、main.log に次のような流れが出ていたとされています。
2026-08-19 09:44:12 — Transport permanently closed for session <id> code=4090
immediately followed by
Transport reconnect failed for session <id>: Request failed with status code 404
この記録だけを見ると、接続が単に「遅い」のではなく、いったん transport が閉じられたあとに再接続が 404 で落ちているようです。ただし、これは issue コメントにある記述であって、こちらの環境で再現確認したものではありません。なので、404 が必ず出るとは言えませんし、原因をそこまで断定もできません。
今回の検証で実際に取得できたのは環境情報だけでした。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-20T08:52:02+09:00
このため、ここでは「この手順をやれば直る」とは書けません。少なくとも、公開された issue だけから言えるのは、次のような見立てです。
connecting のまま止まる場合と、タイムアウト文言が返る場合がある。#95609 #87720もしこの文字列に当てはまるなら、次に見るべきなのは「そのセッションが以前に Remote Control された履歴を持っているか」「別セッションや別経路ではつながるか」です。そこが分かると、今回の issue 群とかなり近いかどうかを判断しやすくなります。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-20T08:52:02+09:00