worker credential expired — re-minting が出たまま Remote Control が戻らないときこの症状は、Remote Control の接続が一度切れたあとに、ホスト側で worker credential expired — re-minting が出続け、再接続が進まないケースです。手元の issue では、Mac はオンラインで Claude desktop app も起動したままなのに、スマホ側では Can't reach <host> の表示が長時間続いていました。報告されているのは #106346 です。もう一つ、同系統として #104769 では、Remote Control のブリッジが数時間後に落ちて、自力では戻れない現象が報告されています。
切り分けの出発点は、単なる一時的な通信断か、それとも credential の再発行に失敗しているかです。#106346 では、セッションが約 13 時間つながったあとに Can't reach gav-m1-mini になり、その後 37 分から 6 時間ほど戻らないとあります。さらに、同じホスト上で新しいセッションは動いていたと書かれています。つまり、マシン全体が落ちているのではなく、既存の Remote Control セッションだけが詰まっている状況です。#104769 でも、worker credential expired のあとに再発行がうまくいかず、work secret refresh skipped (no_poll_in_time) が繰り返される、というログが示されています。
issue にあるログの要点はかなりはっきりしています。worker credential expired が出たあと、更新のたびに work secret refresh skipped (no_poll_in_time) になり、後から poll がたまたま成立したときだけ再接続する、という流れです。報告者は、3 回分のエピソードで同じ挙動を確認しています。引用できる範囲の実測ログは次のとおりです。
2026-10-30 11:40:18 [info] [remote-control] bridge_state: "reconnecting" — "worker credential expired — re-minting
この断片だけでも、問題が「接続先が見えない」のではなく、「worker credential の更新待ちでブリッジが再接続状態に張り付いている」ことが読み取れます。#104769 の報告では、Require trusted devices を有効にした環境で Desktop app の Remote Control bridge が再発行できず、最初の接続すら HTTP 403 で失敗する、とされています。さらに、いったん trusted-devices のルールを外して接続し、その後に戻すとつながるが、数時間後の credential 更新でまた落ちる、という再現パターンが書かれています。現時点では、これはユーザー側の端末や回線だけの問題ではなく、Desktop app 側の Remote Control ブリッジの再認証・再発行処理に関係している可能性が高い、というところまでしか言えません。
手元の一次情報は環境メモのみです。症状の再現確認やログ採取の補助には使えますが、原因の断定には足りません。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-11-01T08:57:41+09:00
この種の症状に当たったら、まず見るべきなのは worker credential expired と、その直後に no_poll_in_time が出ているかどうかです。両方がそろっているなら、少なくとも issue 上では「再発行のタイミングで poll が噛み合わず、ブリッジが自力復帰しない」ケースにかなり近いです。逆に、この文字列が出ていないなら、別の切り分けを考えたほうがよさそうです。現時点で公開されている報告だけでは、恒久的な回避策は確立していません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-11-01T08:57:41+09:00