ScheduleWakeup with a slash-command prompt re-enters that slash command on an already-completed task

What happened

User invoked /plan <args> in auto mode. Plan was approved and execution began. While waiting on a long-running step, the agent (me) internally:

1. Kicked off a long poll via Bash(run_in_background: true) against a GitHub Actions workflow — this tool already emits a completion notification when the background command exits.
2. Also called ScheduleWakeup(prompt: "/plan <args>", delaySeconds: 240) as a parallel "wake me when enough time passes" mechanism, passing the original /plan <args> string back verbatim per the ScheduleWakeup description ("pass the same /loop input verbatim each turn so the next firing re-enters the skill").

Both tool calls were made by the agent, not by the user.

When the wakeup fired, the runtime re-fed /plan <args> as a fresh user turn. That dropped the agent back into plan mode for a task that was already completed and verified. The system-reminder framed it as "Re-entering Plan Mode" and pointed at the existing plan file, nudging the agent to edit the plan rather than recognize the task was done.

Why it's a bug (not just operator error)

Two separate issues stack:

1. ScheduleWakeup's prompt field doesn't distinguish "resume this task" from "re-fire this slash command." The tool description tells the agent to pass the originating user input verbatim. For /loop-style dynamic pacing that's fine. For a one-shot command like /plan, passing it verbatim re-triggers the command's side effects (entering plan mode, blocking tool use) on a task that no longer needs planning. There is no sentinel for "just resume me, no slash-command replay" analogous to the existing <<autonomous-loop-dynamic>>.

1. ScheduleWakeup layered on top of run_in_background is double-booked waiting. The background Bash already emits a completion notification when the polled condition is met. Adding ScheduleWakeup on top is redundant and, because of issue (1), actively harmful when the originating turn was a one-shot slash command. The ScheduleWakeup description warns against polling via chained sleeps but doesn't warn against pairing with run_in_background for the same signal.

Reproduction

All steps after (1) are agent-initiated tool calls, not user input:

1. (User) Invoke /plan <args>, approve the plan, start executing in auto mode.
2. (Agent) Kick off a long poll via Bash(run_in_background: true).
3. (Agent) Also call ScheduleWakeup(prompt: "/plan <args>", delaySeconds: 240) following the tool's "pass the same input verbatim" guidance.
4. Let the background task complete first.
5. When the wakeup fires, plan mode re-engages with a system-reminder saying "Re-entering Plan Mode" on a task that is already done.

Suggested fixes

Either or both:

• Add a <<resume>> sentinel for ScheduleWakeup.prompt that fires a bare continuation, no slash-command replay — parallel to the existing <<autonomous-loop-dynamic>> sentinel.
• Update the ScheduleWakeup tool description to explicitly call out: don't pair with run_in_background for the same signal, and don't pass one-shot slash commands verbatim — only /loop-style skills are safe to re-fire.

Environment

• Claude Code CLI, auto mode, Opus 4.7 (claude-opus-4-7)
• Date observed: 2026-04-20
• Reproducible from the tool description alone; no private repo context needed.