Claude Codeの上限到達時の自動再開がRemote Control中は始まらない件

autoContinueAtUsageLimitをオンにしていても、Remote Controlが接続中のセッションでは、5時間枠の上限に当たったあとに自動で再開しません。画面には上限エラーが出るだけで、リセット後もセッションは止まったままです。この挙動はドキュメントに載っている仕様の範囲ですが、「待ちが始まらなかった」ことが画面に出ないため、寝ている間に回した作業が朝まで止まっていたという形で表に出ます。GitHubのissue #100650は、エラーを出さずに止まるこの挙動に通知を出すか、Remote Controlでも自動で待つよう求める報告です。

自動再開の設定そのものはClaude Codeの上限リセット後に自動再開する設定と止め方で扱っています。ここでは、Remote Controlと組み合わせたときに何が起きるかに絞ります。

ドキュメントは「自動では始めない」と書いている

自動再開の節には、Claude Codeが自分から待ちを始めない場合の一覧があります。3項目あり、最初がRemote Controlとエージェントチームのチームメイトセッションです。理由として書かれているのは「そのターミナルにいる人が手動で始められる」という一点だけです。

つまり「Remote Control接続中は自動で始まらない」こと自体はバグ扱いではなく、仕様どおりです。issueが問題にしているのは、仕様どおりに動いた結果が画面に何も出ない点です。上限に当たって自分の端末で操作しているときは、リセット枠1回につき1度だけ待ちを選ぶメニューが開きます。Remote Control経由のセッションではこのメニューも開かないため、メニューの存在に気づく機会がありません。

issueで報告されている症状

起票者の環境は、Claude Code 2.1.295、Linux x86_64、Claude Maxのclaude.aiログイン、フルスクリーンTUIです。~/.claude/settings.jsonにautoContinueAtUsageLimit: trueを入れ、/configでも同じ設定を有効にしています。再現手順は3段階です。

起票者は過去60日分のローカルのトランスクリプトを集計し、次の数字を示しています。Remote Controlが接続されていたかどうかは、トランスクリプトにbridge-sessionの記録があるかで判定しています。

拒否されたリクエストのquotaLimitsは両グループで同じで、statusがrejected、rateLimitTypeがfive_hour、isUsingOverageがfalseでした。上限の種類や課金状態の違いでは説明がつかない、という見立てです。サンプルは8セッションと小さく、起票者自身が2.1.289と2.1.295では上限に当たっていないと断っています。

報告は複数の環境から続いている

起票後のコメントでは、別の環境でも同じ症状が報告されています。

issueは起票から数日の間に、バージョンもOSも違う報告が重なっています。共通しているのはRemote Controlの併用です。コメントの2件ではremoteControlAtStartup: trueが設定されており、Remote Controlが全セッションで自動接続される状態だったことになります。自動接続をオンにしていると、/remote-controlを自分で打っていなくても接続中になっているため、原因に気づきにくくなります。

手動で待ちを始めると一度だけ動く

2.1.299の報告は、手動の経路についても具体的です。/rate-limit-optionsでWait here, then continue automaticallyを選ぶと、待ちが始まってリセット後に再開します。ところが、その再開のあとにもう一度上限に当たると、同じセッションでは待ちが始まりません。画面のフッターにも理由は出ません。

2.1.303(Windows 11)の報告でも、同じ手動の操作でUsage limit reset · continuing automaticallyが表示されて再開しています。手動の経路が動くことは3件の報告で一致しています。

原因として報告者が示しているコード

起票者とコメント投稿者は、どちらもClaude Codeのバンドルを読んで原因の候補を挙げています。rate_limitのAPIエラーが来たときに待ちを始める関数が、次のような判定で早期に抜けるという読みです(2.1.295のバンドルから報告者が抜き出した断片で、関数名は難読化されています)。

if(cm())return!1
function cm(){return id()||Lt()||J_()!==void 0}
// id() = surfaceCapabilities.replBridgeActive()  ← Remote Control

3つの条件のどれかが真なら自動では待ちません。id()がRemote Controlの接続中、残りの2つがバックグラウンドセッションとチームメイトに当たるというのが起票者の説明です。手動の経路はこの判定を通らないので動く、ためです。2.1.299のバンドルにも同じ構造が残っていると、コメント投稿者が書いています。

これはバンドルを読んだ報告者の推測で、Anthropic側の説明ではありません。ドキュメントの「Remote Controlは自動では始めない」という記述と矛盾しない一方、「手動の一度きり」という挙動までは仕様として説明されていません。

自分のセッションが該当するかを切り分ける

/rc activeの表示は、ターミナルの幅が狭いと隠れます。幅が足りないときは/remote-controlを実行すると、接続状態のパネルが開きます。パネルには切断の操作もあり、切断してもローカルのセッションは動き続けます。remoteControlAtStartupが設定ファイルに入っているかは、/configのEnable Remote Control for all sessionsでも確かめられます。

回避策 — 手動で待つか、Remote Controlを外す

取れる手は2つです。

1. 上限に当たったら/rate-limit-optionsを実行する。Remote Controlのまま、手動で待ちを始められます。ただし席にいることが前提で、無人運転には使えません。再開後に再び上限に当たったら、もう一度実行する必要があります。
2. 無人で回す前にRemote Controlを外す。自動接続を使っているなら、ユーザー設定で止めておきます。

~/.claude/settings.jsonに次のキーを入れます(他のキーは残します)。

{
  "remoteControlAtStartup": false
}

2つ目は、起票者が示した判定が原因だった場合の対処で、Remote Controlを切れば待ちが始まるかどうかをissueは検証していません。報告者の読みが正しければ効くはずですが、夜間に回す前には短い作業で上限に当てて確かめるのが確実です。remoteControlAtStartupはプロジェクトの設定ではtrueが無視されるため、オンにしているのは自分のユーザー設定か管理者のmanaged settingsのどちらかです。

別の副作用もあります。Remote Controlを外すと、手元以外の端末からそのセッションを操作できなくなります。スマートフォンから進捗を見たい用途とは両立しないので、Remote Controlが必要な場面では、上限に近づいたら/usageで残りを見て手動で待つ運用になります。

自動再開が働く場合でも上限は残る

Remote Controlを使わない通常のセッションでも、再び上限に当たったときの再設定は連続で2回までです。3回目にはAutomatic continue stopped after repeated usage-limit hits · /rate-limit-options to try againと出て止まります。2.1.299のコメントは、この回数がバンドル内で2に固定されていると指摘し、メインスレッド以外(サブエージェントなど)で上限に当たった場合は再設定されないとも書いています。サブエージェントを多用する長い無人作業では、同じ「止まったまま」が起きる可能性のある条件です。ドキュメントに載っているのは回数が2であることまでで、メインスレッド以外の扱いは報告者の読みです。

issueの要望は2点でした。Remote Controlでも自動で待つこと。あるいは待たないなら、上限の場でその旨と/rate-limit-optionsの案内を出すことです。どちらも入っていない間は、Remote Controlを併用するセッションで「待ちが始まったか」を目で確かめるのが最も確実です。Usage limit reached · continuing automatically at …の行が出ていなければ、その場で/rate-limit-optionsを実行します。

Remote Controlの接続自体が切れて止まるケースは別の話で、Remote Controlの「could not renew」警告の意味と26時間の猶予や「couldn't refresh your login」で止まる原因が扱っています。上限の待ちと接続の維持は別々の仕組みなので、どちらで止まったかを分けて見ると切り分けが早くなります。

まとめ

Remote Control接続中は自動再開が始まらないというのは、ドキュメントに載っている仕様です。報告されている問題は、その結果が画面に出ず、手動の待ちも1回しか効かないように見える点にあります。夜間や外出中に作業を回すなら、Remote Controlを外すか、上限に当たる前後で自分が画面を見られる状況かを先に決めておくほうが、朝に止まったセッションを見つけるより損が少ないです。