この症状は、少なくとも 2 つの報告に分かれていました。ひとつは、スリープ解除後に Desktop App が再接続を 3 回試したあとで止まり、それ以上の自動再試行をしなくなるケースです。もうひとつは、headless Linux 上で claude のサブコマンドが --version を除いて固まり続けるケースです。どちらも、ユーザー側から見ると「応答が返らない」「つながらない」という形で見えますが、現れ方はかなり違います。
まず、スリープ復帰まわりの報告は #78666 です。報告では、クライアント機が sleep/wake したあと、ネットワークがまだ戻っていないタイミングで Desktop App が transport dead を検知し、その後に自動再接続がちょうど 3 回、約 6 秒の間に走るとされています。3 回とも host is offline で失敗し、その後は Auto-reconnect exhausted になって自動では再試行しない、という内容でした。サーバープロセス自体はその間も動き続けていた、と書かれています。つまり、少なくともこの報告では「サーバーが落ちた」のではなく、「クライアント側の再接続が早すぎて空振りし、その後止まる」ことが問題です。
もうひとつの #90800 は、かなり別の顔をしています。headless な Ubuntu/Debian 系 Linux で、claude のほぼ全サブコマンドが無限に hang し、--version だけは通るという報告です。stdout/stderr は出ず、300 秒以上待って外部タイムアウトで止めても状況は変わらない。さらに strace では、複数スレッドが pread64() の短いループを回し続け、futex や madvise が目立つが、ブロック系 syscall やネットワーク待ちには見えない、とされています。報告者はこれを過去の類似 issue 群と重ねていますが、現時点でこの issue 自体は未解決です。
筆者の環境で実際に取れた出力は、ここだけです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-15T08:51:24+09:00
このため、少なくとも自前の一次情報から断定できるのは、検証環境が Linux 3.10 系であることまでです。ETIMEDOUT の直接発生条件、Desktop App の再接続挙動、headless Linux での hang 再現は、この出力だけでは確認できません。
見分け方は単純です。スリープやネットワーク復帰の直後に起きるなら #78666 側の再接続失敗が近いですし、--version 以外の claude 実行がどれも返ってこないなら #90800 の系統が疑わしいです。前者は「最初の数回の再接続はあるが、その後止まる」、後者は「そもそもコマンドが戻らない」という違いがあります。
現時点では、どちらの報告にも確立した解決策は書かれていません。したがって、この記事で書けるのは「この 2 つの issue で報告されている事実」と、「自分の症状がどちらに近いかを切り分ける観点」までです。ETIMEDOUT が出ていても、復帰直後の一時的な通信失敗なのか、Linux 環境での恒常的な hang なのかで見え方が変わります。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-15T08:51:24+09:00