Claude Codeのバックグラウンドで/loopが止まる — wakeupが発火しないときの再開方法
バックグラウンドセッションの自己ペース/loopが「restarted after its next /loop wakeup was due」の通知で止まる理由と、返信して再開する手順、v2.1.295より前との違いをまとめます。
バックグラウンドセッションで回していた自己ペースの/loopが、ある時点から動かなくなる。agent viewを開くと、次のような通知が出ています。
This session restarted 12m after its next /loop wakeup was due, so that wakeup will not fire. The loop stays stopped until Claude schedules it again: reply to continue it.結論から言うと、これはエラーではなくループが止まったことを知らせる通知です。セッションのプロセスが待機中に終了し、次のwakeup(再開予定時刻)が、次のプロセスの起動より先に来てしまった状態を指します。取り逃したwakeupは、あとから遅れて発火しません。直すには、そのセッションに返信して、ループを続けるよう伝えます。
この通知はどんな状態を表しているのか
対象は、間隔を省略した自己ペースの/loopを、バックグラウンドセッションで動かしている場合です。Claudeが1回の実行ごとに次の待ち時間(1分〜1時間)を決め、その時刻にwakeupを予約する方式でした。
通知の中身は3つの事実でできています。
- セッションのプロセスが、ループの待機中に終了した
- 次のwakeupの時刻は、次のプロセスが立ち上がる前に過ぎていた
- 過ぎたwakeupは発火せず、ループは止まったままになる
文面の12mは、プロセスが再起動した時点でwakeupがどれだけ遅れていたかを示します。数値は状況によって変わります。
ここで大事なのは、遅れて1回だけ走るという救済がない点です。通常のセッションでは、Claudeが長い処理で忙しいうちに予定時刻が過ぎた場合、手が空いた時点で1回だけ発火します。今回の状況は別で、そもそも動いているプロセスがない間に時刻が過ぎるため、予約が失効します。
通知が出たとき、最初に浮かびやすい疑問
- 後輩
ループが止まったのは、Claudeがタスクを終えたからではないんですか。
- 先輩
違います。タスク完了なら、Claudeが
stop: trueでwakeupを取り消します。今回の通知は、予約されていたwakeupが取り逃されたことを知らせるものです。 - 後輩
放っておくと、そのうち再開しますか。
- 先輩
しません。Claudeが次をスケジュールし直すまでループは止まったままです。きっかけとして返信が要ります。
続けたいときの手順
再開に特別なコマンドはありません。agent viewで該当セッションの行を選び、Spaceでpeekパネルを開いて返信を送ります。返信は、通知と一緒にClaudeに渡ります。Claudeがその通知を読み、次のwakeupを改めて予約します。
止まった/loopを再開する
- 1
agent viewを開く
シェルで
claude agentsを実行します。止まったループのセッションは、行を選んで内容を確認できます。 - 2
peekパネルで通知を確かめる
対象の行で
Spaceを押します。restarted ... after its next /loop wakeup was dueの通知が出ていれば、この記事の状態です。 - 3
返信を送る
入力欄にループを続ける旨を書き、
Enterで送ります。
返信の文面は、たとえば次のような短いもので足ります。例はkeep the loop runningという一言です。
keep the loop running元の指示を書き直す必要があるかどうかは、errorsのページに記載がありません。ループの目的が会話に残っていれば、Claudeは通知と返信を読み、そのまま次のwakeupを予約できます。心配なら、「CIの通過とレビューコメントの確認を続けて」のように、対象を一言添えておくと確実です。
反対に、ループがもう不要なら何もしなくて構いません。すでに止まっています。
返信するとセッションは再起動の経路に入るため、∙(プロセスが終了した状態)のアイコンのセッションに返信した場合でも、Claudeは保存済みの会話から再開します。
なぜプロセスが途中で終了するのか
公式のページは、プロセスが終了した理由までは特定していません。ただし、バックグラウンドセッションのプロセスが止まる経路は、agent viewの説明にいくつか書かれています。この通知の原因として考えられる場面を、そこから拾います。
| 経路 | プロセスの扱い |
|---|---|
| 作業中・ダイアログ待ち・アタッチ中 | プロセスの扱い動き続ける。保留中の/loopのwakeupも「作業中」に数えられる |
| 想定外の終了 | プロセスの扱いスーパーバイザー(supervisor)が動いていれば、プロセスを再起動する |
| スーパーバイザー自体の停止 | プロセスの扱いmacOSとLinuxでは、各プロセスが約1分、新しいスーパーバイザーの再接続を待つ。来なければ停止する |
| 自動更新 | プロセスの扱いスーパーバイザーが新しいバージョンへ自分を再起動し、アイドルのセッションを移す。作業中・入力待ち・アタッチ中は中断しない |
wakeupを待っている/loopのセッションは、動き続けるグループに入っています。それでも通知が出るのは、プロセスが想定外に終了して再起動された場合のように、表の外側で途切れた場面があるからです。どの経路が引き金になったかは、通知の文面だけでは判別できません。
手がかりを探すなら、スーパーバイザーの状態を見ます。claude daemon statusは、スーパーバイザーに到達できるか、プロセスIDとバージョン、稼働中のバックグラウンドセッション数を表示します。ログは~/.claude/daemon.logにあります。
claude daemon statusスーパーバイザーがバージョン違いで動いていると、同じコマンドが警告を出します。その場合はclaude daemon stop --anyで止めると、次の起動で新しいバージョンに揃います。ただし、このコマンドは稼働中のバックグラウンドセッションごと止めます。作業中のセッションがないことを確かめてから実行してください。
v2.1.295より前との違い
v2.1.295より前は、同じ状況でループが通知なしに止まっていました。通知の有無が変わっただけで、wakeupが発火しない点は変わっていません。
つまり、古いバージョンで「何も起きないまま止まった」ように見える場合も、原因は同じと考えられます。新しいバージョンでは、止まった事実が通知として会話に残るため、気づける機会が増えました。通知の文面が出ないのに止まっている場合は、バージョンを確認してください。
claude --version通知が出ないのにループが動かないときの切り分け
peekパネルに「restarted ... after its next /loop wakeup was due」の通知があるなら、この記事の状態です。返信してループを続けるよう伝えます。
通知が出ないのに止まっているときは、scheduled-tasksのページが挙げる別の停止要因を順に確かめます。
/loopが動かないときの確認順
- Q自分でEscを押した、またはClaudeが完了と判断した覚えがあるか答えがある答えがはい
Escは保留中のwakeupを消し、Claudeはstop: trueでループを終えられます。いずれも意図した停止なので、再開するなら/loopをもう一度実行します。 - Q`--resume`や`--continue`でセッションを開き直したか答えが開き直した答えがはい
自己ペースの/loopは、再開時に復元されません。
/loopをもう一度実行します。
どちらでもないとき
固定間隔のループ、定期タスク、自己ペースの/loopのいずれにも、作成から7日の有効期限があります。期限が過ぎていないか確認します。
1回の実行がスケジュール変更も停止もせずに終わった場合も、ループは終わります。この場合は約20分後にフォールバックのwakeupが1回予約され、それでも次を予約しなければ終了します。今回の通知とは別の止まり方で、通知は出ません。
予防できるか
通知を完全に避ける設定は、公式のページには載っていません。実務では、次の2点で影響を小さくできます。
- 止まって困るループには、完了条件を決めたうえで定期的にpeekで様子を見る。agent viewで
✢のアイコンと実行回数のカウントダウンが出ているセッションが、待機中のループです - 長く回すループは、CIの通過待ちのように目的が明確な指示にしておく。再開の返信が一言で済みます
なお、確実に無人で回し続けたい定期処理は、セッションに依存しない手段のほうが向いています。scheduled-tasksのページは、クラウドで動くRoutines、GitHub Actionsのscheduleトリガー、Desktopのスケジュールタスクを挙げています。
似た名前のバックグラウンドセッションのエラーとの違い
バックグラウンドセッションには、これ以外にも対処が決まっている通知がいくつかあります。
- ターミナルホストのプロセスが死んだ場合は、agent viewで
Enterを押すかclaude attach <id>で再起動できます - 応答がない場合は、
claude stop <id>のあとにclaude attach <id>を実行します - 対話ダイアログを開けないコマンドは、Commands refusedエラーとして拒否されます
どれも会話は保存されたままで、再開すれば続きから進められます。今回の通知だけは、再開しても自動ではループが戻らず、返信を一度挟む必要がある点が違います。
まとめ
自己ペースの/loopがバックグラウンドセッションで止まり、「restarted ... after its next /loop wakeup was due」の通知が出たら、wakeupは失効しています。続けたいときは、そのセッションにpeekで返信してkeep the loop runningと伝えます。続けないなら、何もしなくて構いません。通知が出るのはv2.1.295以降で、それより前は黙って止まっていました。