Remote Control接続時は自動継続せず

作者の構成は特定のワークフローを狙っている。OpusのメインセッションがSonnetのサブエージェントを並列で起動し、86チケットのハッカソンプロジェクトを実行する。この実行はセッション上限に達したが自動継続せず、作者は23:40のリセット時に手動で「continue」と入力する必要があった。報告された証拠はトランスクリプトに基づき、10分以内の上限到達を数えている。合計29回で、Remote Control接続中は10回中10回とも自動継続に失敗し、未接続時は8回中8回とも開始した。状態が切り替わった1つのセッションが傾向を明確に示している。/remote-control開始前の3回、開始後の3回は始まらなかった。作者はまた、バージョン2.1.289の同梱CLIコードではRemote Control接続時に待機を開始する関数が即座に戻ると述べ、これは変更されうる内部実装だと注記している。

回避策は組み込みの自動継続を有効にしたまま4つのフックを重ねる。StopとStopFailure(rate_limit)はリセットを待ってasyncRewakeでexit 2によりセッションを起こす再開ステップを実行する。UserPromptSubmitは使用状況のコンテキストを追加し、週間ライン以上で組み込みの継続プロンプトをブロックする。PreToolUseゲートはエージェントの起動や継続の前に確認を求める。検証は実際のインタラクティブセッションでの2回のプローブと35件の単体テストだが、作者は実際の5時間リセット、週間85%超の挙動、ライブのrate_limit StopFailureは偽データを使った単体テストのみで実施されたと述べている（Claude Code 2.1.289、macOS、Maxプラン）。

ここでの争点は、組み込みの除外が将来のClaude Codeバージョンでも続くか、フックの経路がテスト環境外でも同じ挙動になるかどうかだ。無人でClaude Codeを動かすことに依存する人にとって実用的な問題は、自分のセッションが気づかないうちにRemote Controlへ接続されていないか（作者はユーザーがコマンドを一度も入力しなくても起こりうると警告している）、そして自分のガードレールがシミュレーションデータではなく実際の上限リセットでテストされているかどうかである。