{"version":"2.1.202","anchor":"loop-explicit-stop-via-schedulewakeup-stop-true","canonical_anchor":"loop-explicit-stop-via-schedulewakeup-stop-true","heading":"\/loop Explicit Stop via ScheduleWakeup({stop: true})","tier":null,"area":null,"scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.202\/e\/loop-explicit-stop-via-schedulewakeup-stop-true","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.202","markdown":"### `\/loop` Explicit Stop via `ScheduleWakeup({stop: true})`\n\n**What**\n\nThe `ScheduleWakeup` tool used in dynamic `\/loop` sessions now accepts a `stop: true` field to explicitly terminate the loop, replacing the previous implicit approach of simply omitting the call.\n\n**Details**\n\n- `stop: true` cancels all pending wakeups and records a terminal event\n- When called after the loop has already ended, it logs a cleanup-only message and suppresses the terminal event to avoid double-firing\n- The `\/loop` instructions now clearly enumerate step 6: \"To stop the loop \u2014 call ScheduleWakeup with `stop: true` (no other fields) ... Stopping is the loop's normal ending \u2014 the user can restart it anytime with \/loop.\"\n- A `loopEnded` flag is now tracked in session state to guard against duplicate stop events\n- A `noop` field was already present; `delaySeconds`, `reason`, and `prompt` are now explicitly documented as required only when `stop` is not true\n- The tool description now reads: \"call with `stop: true` to end the loop immediately\" (was: \"omit the call to end it\")\n\n**Evidence**\n\nLoop stop handler (search for `\"[loop] model called ScheduleWakeup({stop:true})\"` and `\"stop the \/loop \u2014 cancel pending wakeups, schedule nothing\"`)"}