ScheduleWakeup off-label use outside /loop (per skill guidance) causes spurious loop-mode UI and prompt redelivery
\ScheduleWakeup\'s own tool description states it's for "/loop dynamic mode" and says "you don't call it directly" — but it's the only wakeup/scheduling primitive Claude Code exposes, so any skill that instructs a bounded idle wait (e.g. Superpowers' \subagent-driven-development\: "wait in bounded stretches (five to ten minutes, where your platform allows)") drives a session to call it off-label, since there's no alternative bounded-wait primitive for non-\/loop\ sessions (\/goal\ is condition-driven, not wait-and-resume).
Repro: interactive tmux session (v2.1.267) mid-execution of a \subagent-driven-development\ plan, never invoked \/loop\, called \ScheduleWakeup\ while waiting on a dispatched background implementer subagent to report.
Observed:
- CLI banner "Claude resuming /loop wakeup (...)" on wakeup, despite \
/loop\never being invoked. - Available-skills list truncated to "1 skill available" on wakeup vs. the full list normally injected.
- On 2-3 occasions, the identical prior prompt ("check whether Task N's implementer has reported") was redelivered as if a new user message — risks double-processing a status check mid-plan.
Related: #88205 (ScheduleWakeup rejects \noop:true\ outside \/loop\ with a validation error) — same off-label-usage root cause, different symptom (hard rejection vs. silent side effects). Changelog 2.1.257 fixed a background session's \state.json\ prompt-repeat on wakeup; this repro is on an interactive session, a different code path, and reproduces on 2.1.267 — after that fix shipped.
Ask: either make \ScheduleWakeup\ safe/rejected-cleanly outside \/loop\ (consistent behavior, not silent side-effects), or document a supported bounded-wait primitive for non-loop sessions that skill authors can safely recommend.