[BUG] CC + Opus 4.8: `ScheduleWakeup` constantly re-injects workflow slash command as an apparent user invocation, causing an unrequested re-run of entire workflow

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

While running a long, stateful slash command (/devmind-build), the assistant called the
ScheduleWakeup tool as a "fallback heartbeat" timer. The timer fired later and re-injected the
original slash command verbatim into the conversation as if the user had typed it, triggering an
apparent unrequested re-run of the entire command. The user did not type the second invocation and
had no indication it was machine-generated.

This is partly an agent-behavior mistake (the timer should never have been set), but it surfaces
several genuine product/UX footguns in ScheduleWakeup / /loop worth fixing.

Environment

| Field | Value |
|-------|-------|
| Claude Code version | 2.1.162 |
| Model | claude-opus-4-8[1m] (Opus 4.8, 1M context) |
| OS | Darwin 25.2.0 (macOS) |
| Session ID | 3189f974-644a-4af5-b587-1d66b1b957fa |
| Tool involved | ScheduleWakeup (the /loop dynamic-mode wakeup primitive) |
| Context | A custom slash command (/devmind-build) that drives a multi-stage, side-effecting pipeline with background subagents |

What happened (timeline)

1. The user invoked a custom slash command: /devmind-build BLOG-1780574427920.
2. Early in the run, the assistant dispatched 4 background subagents (run_in_background: true) and

then called ScheduleWakeup as a "fallback heartbeat" in case the agents hung:

• delaySeconds: 270
• prompt: "/devmind-build BLOG-1780574427920" (the original invocation, passed verbatim)
• reason: "Fallback heartbeat while 4 research agents run; harness notifies on completion first."

1. Tool result returned:

> Next wakeup scheduled for 14:02:00 (in 246s). Nothing more to do this turn — the harness
> re-invokes you when the wakeup fires or a task-notification arrives.

1. The background agents completed normally and the harness delivered completion notifications, so

the assistant continued and ran the entire /devmind-build pipeline to completion (many more
minutes of wall-clock work). The pending one-shot wakeup was never cancelled.

1. Some time later the wakeup timer fired and re-injected /devmind-build BLOG-1780574427920 into

the conversation. It arrived formatted exactly like a user-initiated slash command:
``
<command-message>devmind-build</command-message>
<command-name>/devmind-build</command-name>
<command-args>BLOG-1780574427920</command-args>
``
There was no marker distinguishing this timer-fired invocation from a real user action.

1. The user saw what looked like the assistant autonomously re-running a command they never issued,

on an already-completed task, and reasonably asked "did you schedule that without my permission?"

Impact

• Apparent autonomous, unrequested execution of a side-effecting command. To the user this is

indistinguishable from the assistant going rogue.

• Token/compute waste. The fired prompt re-entered a heavy multi-agent pipeline.
• Trust damage. A timer silently re-issuing the user's own command, with no visible provenance,

feels like the agent is acting without consent.

Root cause

Two layers:

1. Agent misuse (acknowledged)

ScheduleWakeup should not have been called at all. The harness already re-invokes the agent on
background-subagent completion, so a "fallback heartbeat" timer is redundant. The tool's own
description even warns against polling for harness-tracked background work. The agent copied the
"pass the same /loop input verbatim each turn" template pattern into a context where it did not
belong.

2. Product/UX footguns (the reportable part)

• Fired wakeups are indistinguishable from user input. The re-injected prompt arrives as a

<command-name>/…</command-name> block with no provenance marker (e.g. no "fired by ScheduleWakeup"
/ "system-generated wakeup" tag). The user — and arguably the model — cannot tell a timer firing
from a genuine user command.

• A wakeup can re-trigger a full slash command, including expensive/stateful ones. There is no

guard or confirmation when a scheduled prompt is itself a heavy, side-effecting command.

• No obvious affordance to cancel a pending one-shot wakeup. Once set, the wakeup fires; the

documented way to "stop the loop" is to omit the next ScheduleWakeup call — but a one-shot timer
scheduled in turn N has no clean cancel path if work then continues for many turns/minutes past it.

• No auto-invalidation. The wakeup still fired even though the turn that scheduled it had long

since ended and the task had run to completion. A wakeup whose originating work is already finished
arguably should not fire (or should be a no-op).

• /loop-oriented primitive is callable in non-/loop contexts where these footguns are easy to

hit, with the same "pass the prompt verbatim" guidance that makes re-execution the default outcome.

Suggested fixes (for Anthropic)

1. Tag timer-fired invocations distinctly from user input (a clear provenance marker the user and

model both see), so a wakeup re-injection is never mistaken for a user command.

1. Provide an explicit cancel for a pending one-shot ScheduleWakeup (and surface that one is

pending), rather than relying on "just don't schedule again."

1. Guard re-execution of side-effecting slash commands fired from a wakeup — at minimum a

confirmation/notice, ideally refusing to silently re-enter a stateful command.

1. Auto-invalidate a wakeup whose scheduling turn/task has already terminated, or make it a no-op.
2. Discourage ScheduleWakeup for harness-tracked background work more strongly at the tool level

(it's documented, but the failure mode here is severe and silent).

What Should Happen?

CC should not silently schedule my entire workflow to run again. It wastes money and tokens.

Error Messages/Logs

Steps to Reproduce

Run a workflow command (skill) and walk away from your computer...

1. In a long-running task that dispatches background subagents, call ScheduleWakeup with

prompt set to the current slash-command invocation (e.g. "/mycommand ARG") and a short
delaySeconds.

1. Let the background work complete normally and continue the task past the scheduled time without

cancelling.

1. Observe the wakeup later fire and re-inject /mycommand ARG as an apparent user command.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.162

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_