Remote Controlが20分放置で切断される原因と回避策

Claude Code Remote Controlのセッションは、机で立ち上げたまま離席すると20〜30分ほどでエラーを出さずに切断されることがあります。ローカルのCLIは「Remote Control active」と表示し続けるのに、スマホ側からは何も送れません。原因はGitHub issue #32982でソースコードレベルまで追跡されており、キープアライブの仕組みが3つともアイドル中には効かない設計になっていたことが分かっています。

20〜30分放置で切断される症状

症状は毎回ほぼ同じ形で出ます。スマホアプリ側は「Failed to send message — An unknown network error has occurred」と表示し、メッセージを送っても届きません。一方でローカルのターミナルは何のエラーも出さず、「Remote Control active」の表示のままです。

issue #32982の報告では、この状態でセッションの受信エンドポイントに直接アクセスするとHTTP 404が返ってきました。サーバー側ではすでにセッションが登録抹消されていて、CLIプロセスだけが自分が生きていることに気づかないまま接続を保持し続けています。TCP接続自体は張られたままなので、CLI側には切断を検知する手がかりがありません。

2026年3月の最初の報告では、放置してから切断までの時間は5〜30分の幅があり、もっとも多いのは約20分でした。7つの独立したセッションで再現率は100%だったとされています。メッセージを大量に送っても切断は起きず、純粋にアイドル時間だけが引き金でした。

3つのキープアライブが揃って効かない構造

issueの報告者は、当時のバージョン(v2.1.72)のcli.jsを静的解析し、切断を防ぐはずの仕組みが3つともアイドル中には機能していないことを突き止めました。

1つ目は5分ごとに送られるWebSocketのキープアライブフレームです。フレーム自体は正常に送られていましたが、サーバー側のセッションTTLはこのフレームを活動としてカウントしていませんでした。加えてCLAUDE_CODE_REMOTE環境変数を使う単体ブリッジモードでは、この5分間隔の送信自体が早期リターンで止まる作りでした。

2つ目はCLAUDE_CODE_REMOTE_SEND_KEEPALIVESという30秒間隔の追加キープアライブです。モデルの処理中だけ増えるrefcountに紐づいており、ツール実行やストリーミングが終わるとカウントが0に戻り、タイマーごと止まります。

// 処理が終わるとrefcountが0になり、キープアライブのintervalごとclearされる
function XD1() {
  C36--;
  if (C36 === 0) {
    if (Dd !== null) { clearInterval(Dd); Dd = null; }
    kE9();
  }
}

アイドル中こそ必要な仕組みが、アイドルになった瞬間に止まる作りだったことになります。3つ目はブリッジ層のハートビートで、コード自体は実装されているものの、サーバーが返す設定値heartbeat_interval_msが0になっており無効化されていました。3つの仕組みが揃ってアイドル中は止まる構造でした。

v2.1.74の修正とその後の再発

issue提出から2日後のv2.1.74では、新しく2分間隔のキープアライブ(session_keepalive_interval_ms、既定値120000ミリ秒)が追加されました。refcountにもCLAUDE_CODE_REMOTE環境変数にも縛られず、アイドル中でも無条件に動く仕組みです。報告者の検証では、このバージョンでセッションが30分以上アイドルにしても維持されたとされています。

ところがその後のバージョンでも、切断の再発報告が途切れていません。バージョンを追うと経緯が見えてきます。

再発の中心はGrowthBookというフィーチャーフラグ配信の仕組みです。v2.1.150を検証した報告者は、2分キープアライブの間隔値session_keepalive_interval_v2_msがコード上は120000を既定値としつつ、サーバーがアカウントごとに0を配信しているケースがあることを見つけました。値が0だとif文の条件を満たさず、タイマー自体が起動しません。

厄介なのは、ユーザー側に有効な回避策がないことです。~/.claude.jsonにキャッシュされた値を書き換えても、次にGrowthBookのフラグが更新されると0に戻ります。DISABLE_GROWTHBOOK=1を設定するとコード側の既定値120000にフォールバックしますが、Remote Control自体の利用可否判定もGrowthBookのフラグに依存しているため、今度は「Remote Control is not yet enabled for your account」というエラーで起動できなくなります。延命の仕組みと機能の有効化ゲートが同じスイッチに乗っているため、片方だけを選べません。

v2.1.233の解析では、クライアントが/worker/heartbeatというエンドポイントにidle_secondsという値を自分から申告している実装も見つかりました。ターンが動いていないときのアイドル秒数を計算して送るしくみで、サーバー側はこの値をもとにハートビート間隔を調整します。Remote Controlが本来対応すべき「離席してアイドルになる」状態そのものを、クライアントが自らサーバーに「なにも起きていない」と申告してしまう構造です。

tmuxのせいだと考える前に

この現象はtmux越しに離席するケースでよく報告されますが、v2.1.233を調べた報告ではtmux自体が原因ではないと明確に否定されています。バイナリを調べてもlist-clientsやsession_attached、client_attachedといったtmuxのクライアント接続を検知する処理は見つからず、ターミナルのフォーカスイベントも配線先がありません。ハートビートは単純なsetTimeoutの連鎖で、ターミナルが描画されているかどうかとは無関係に動きます。

tmuxが疑われるのは、tmuxが「離席してアイドルにする」ための手段として広く使われているからにすぎません。同じ報告では、同じtmuxサーバー上で自律的に長時間動くセッションは一度も切断されず、アイドルのまま放置したセッションだけが切断されたと記録されています。tmuxのデタッチ自体を疑って設定を変えても、根本原因には触れられません。

GrowthBookのフラグ配信値による影響の違い

再発の実態は「利用形態」ではなく「アカウントに配信されているフラグ値」で分かれます。v2.1.220(paisanllc)は通常の--remote-control起動、v2.1.246(bautrey)は11個の名前付きセッションを常時起動する運用でしたが、どちらもセルフホストのブリッジではなく、それぞれのアカウントにフラグ値0が配信されていたことが原因でした。

公式ドキュメントの利用条件には、DISABLE_TELEMETRY・DO_NOT_TRACK・CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC・DISABLE_GROWTHBOOKのいずれかを設定しているとRemote Controlが使うフィーチャーフラグ判定自体が止まる、と明記されています。プライバシー目的でこれらの変数を設定している環境ほど、アイドル切断以前に起動そのものへ影響が及ぶ点は覚えておく価値があります。

OSやホストプロセスの種類による違いも報告されています。2026年8月25日の報告では、同じWindows 11機でもPowerShellから直接claudeを起動したセッションは1週間以上維持された一方、Claude Desktopアプリ経由で起動したセッションは数時間で切断されたとされています。2026年9月9日の報告ではWindows PowerShellでは発生せずDebian環境でのみ発生したという逆方向の観察もあり、切断の起こりやすさはOSそのものよりもホストプロセスの種類やアカウントへのフラグ配信状況に左右されている可能性があります。

回避策 — アイドルを前提にした運用でカバーする

issue報告当時の回避策は単純です。15分おきに端末から実際のメッセージを送ると、サーバー側のTTLがリセットされます。キープアライブフレームはTTLに数えられませんが、モデルを実際に動かす通常のメッセージはブリッジを通る本物の活動として扱われるためです。

そろそろ確認 - まだ作業中です

送る内容自体に意味は要りません。重要なのは自動延命の仕組みを別途用意することではなく、長時間アイドルにしたい時間帯があるなら定期的に一言送るという運用でカバーする発想です。

切断されたあとの復旧は難しくありません。公式ドキュメントは「could not reach the Remote Control server for about 30 minutes」というメッセージが出た場合、/remote-controlをもう一度実行すれば再接続できると案内しています。ただし2026年8月26日の報告(v2.1.246)では、スリープもネットワーク切断も排除した環境で11個の同時セッションを走らせても同じメッセージが出ており、再接続の手間そのものは残っています。

DISABLE_GROWTHBOOK=1は前述のとおりRemote Control自体を止めてしまうため、切断対策として設定しないほうが安全です。

他の接続トラブルとの切り分け

Remote Controlの接続エラーにはアイドル切断以外にもいくつか系統があります。サインインの種類や組織のポリシーに起因するもの、resumeで再接続できないケース、Trusted Devicesの端末登録が絡むものなどです。これらは症状も対処もアイドル切断とは別物なので、Remote Controlに接続できないときの見分け方と対処にまとめています。基本的な起動方法や利用条件はClaude Code Remote Controlで作業を別デバイスに引き継ぐ、Remote Control周りの修正を含むリリースの詳細はClaude Code v2.1.238で確認できます。

まとめ

Remote Controlのアイドル切断は、サーバー側のセッションTTLと3つのキープアライブ機構の噛み合わせという、issue #32982が突き止めた具体的な原因を持つ現象です。v2.1.74で一度は改善されましたが、その後もアカウント単位のフラグ配信次第で15〜20分程度に戻るという報告が続いています。切断そのものを完全に防ぐクライアント側の手段はなく、アイドルにしたい時間帯があるなら定期的にメッセージを送る、切断されたら/remote-controlで再接続する、という運用で付き合うのが現実的です。GrowthBook関連の環境変数を安易に触ると、Remote Controlの起動自体を止めてしまう点にも注意が必要です。