{"version":"2.1.307","anchor":"command-lifecycle-frames-report-scheduler-wakeups-interrupt","canonical_anchor":"command-lifecycle-frames-report-scheduler-wakeups-interrupt","heading":"SDK hosts can tell scheduled wakeups from user prompts and see requeued prompts","tier":"use","area":"Agents","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.307\/e\/command-lifecycle-frames-report-scheduler-wakeups-interrupt","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.307","markdown":"### SDK hosts can tell scheduled wakeups from user prompts and see requeued prompts\n\nCommand start messages to SDK hosts now say when a run was woken by \/loop or a schedule, and interrupt replies list prompts put back in the queue\n\n**What**\n\nThese changes affect programs that drive Claude Code through the SDK or the streaming JSON protocol, rather than people typing in the terminal. Such a program is called a host.\n\nTwo messages Claude Code sends to the host carry more detail:\n\n- The message saying a command has started now includes `wakeup_source`, set to `loop_wakeup` or `schedule_wakeup`, and `scheduled_for`. A host can tell a run that `\/loop` or a scheduled task woke up apart from a prompt a person sent.\n\n- The reply to an interrupt now includes `put_back`, a list of the prompt IDs the interrupt returned to the queue. This happens for prompts sent with `requeue_if_interrupted_within_ms`, which asks Claude Code to queue a prompt again if it is interrupted within that many milliseconds.\n\nClaude Code announces support for these in the system message it sends when a session starts.\n\n**Why**\n\nHosts that keep an idle session open so `\/loop` can wake it get a precise signal for why a run began, and can see which prompts an interrupt did not throw away.\n\n- Area: Agents\n- Tier: Use it now\n- Useful: 3\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: no"}