この症状は、少なくとも今回渡された 2 件の issue では、「最初の 1 回だけ返らない」「新しいセッションだけ固まる」 という形で出ています。
ただし、どちらも原因の切り分けはまだ確定していません。現時点で言えるのは、無反応の時間が長いのに、その間 transcript に何も書かれない という点です。
まず、自分のケースかどうかを見ます。
/compact のあと、最初のメッセージだけが長時間止まるこれに当てはまるなら、今回の症状クラスタと近いです。
#106580 では、WSL2 上で /compact 後またはアイドル後の最初の API リクエストが、約 10 分止まる と報告されています。報告者の観測では、止まっている間は transcript に何も書かれず、その後に instructions、session_context、credential_org、remote_session_change の添付と API リクエスト、応答がほぼ 1 秒以内にまとまって出ています。つまり、待ち時間は会話の途中ではなく、ターン開始時のコンテキスト再構築っぽい部分 に寄っているようです。
#102635 は、Windows の Claude Desktop で、WSL を向いた新しい Code セッションだけ が最初のメッセージで固まるという報告です。古いセッションは動くのに、新しく作ったセッションだけ止まる、という切り分けが入っています。本文中のコメントでは、SessionStart の hook に asyncRewake: true と長い timeout があると、新規セッションの初回メッセージで止まるケースが見つかったとされています。別のコメントでは Stop 側でも似た挙動が観測されていますが、どちらもコメントベースの候補であって、一般解として確定したわけではありません。
今回、こちらで実際に確認できた設定ファイルの出力は次のとおりです。
[settings_structure]
~/.claude/settings.json: (存在しない)
/mnt/vda5/git/papoo/newsbot_openai/.claude/settings.json: (存在しない)
/mnt/vda5/git/papoo/newsbot_openai/.claude/settings.local.json: (存在しない)
このため、少なくとも筆者の検証環境では、設定ファイルの中身を使って原因を追う材料はありませんでした。
したがって、ここから先で「このキーが悪い」とは言えません。分かるのは、手元では該当ファイルが見つからなかった ということだけです。
もし同じ症状を見ているなら、次の順で切り分けるのがよさそうです。
初回の 1 メッセージだけ遅いのかを見る
途中のターンが普通なら、開始処理側の問題が疑わしいです。
/compact の直後だけか、アイドル後だけかを分ける
#106580 ではこの 2 つが同じクラスタとして見えています。
新しいセッションだけか、既存セッションでも起こるかを分ける
#102635 では、新規セッションだけが止まっています。
SessionStart や Stop の hook があるなら、一度そこを疑う
ただし、これは issue コメントで報告された候補にすぎません。
実際に自分の環境で同じことが起きるかは、まだ分かりません。
現時点では、「Remote Control connect timed out」という表示そのものに対する確定的な対処は、渡された情報の範囲では出せません。
少なくとも今回の issue 群では、初回応答の前に待ちが入る こと、その待ちが非常に長い こと、そして hooks やセッション開始処理が関係していそう というところまでです。そこから先は、追加の再現条件とログが要ります。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-11-02T08:56:30+09:00