ScheduleWakeup rejects noop:true calls made outside /loop with "prompt is required when stop is not true"

Status Open
Reported on v2.1.237
Maintainer reply None cached
Activity 1 comment · opened Aug 20, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet (closest are #86245, #74569, #82633 — all about different ScheduleWakeup failure modes; none match this exact validation error)
  • [x] This is a single bug report

What's Wrong?

ScheduleWakeup rejects a call with noop: true (no stop, no prompt) with:

Error: `prompt` is required when `stop` is not true.

This happened outside of /loop — the session was running the /investigate skill (which internally invoked pm-plan), not a dynamic loop. Both investigate and pm-plan are third-party skills installed from pmatos/skills (https://github.com/pmatos/skills.git) via the skills CLI — they are not built into Claude Code. I checked their SKILL.md and reference files directly: neither mentions ScheduleWakeup or noop anywhere. So this isn't a skill instructing bad tool use — the model reached for the built-in ScheduleWakeup tool on its own initiative while waiting on background agents.

The model wanted to note "nothing changed, still waiting on background agents" and picked ScheduleWakeup with noop: true as a heartbeat, since the tool is generally available and its description frames noop as exactly "nothing changed / still waiting" semantics. It has no /loop prompt to hand back, so it omitted prompt — and the call was rejected.

The tool's own schema/description ties prompt to "unless stop is true," with no accommodation for a call that is neither continuing a /loop nor stopping one — i.e. a one-off diagnostic/heartbeat call made outside /loop context entirely. Either:

  • ScheduleWakeup should not be reachable/attractive outside an active /loop (e.g. omitted from the toolset, or its description should make the /loop-only contract explicit), or
  • the validation should accept noop: true without prompt when there's no loop to continue.

Right now a model can construct a call that reads as valid by the tool's own description (noop for "nothing changed") and still get a hard validation error.

Repro Transcript

From session 3b949405-45d8-4753-b689-417da49e5186, running Claude Code v2.1.237, claude-sonnet-5, inside the /investigate skill (not /loop):

Assistant text:

Confirmed. I'll wait for the three research agents to finish, then draft the sliced plan, and afterward edit #526 into an epic tracker with one self-contained issue per seam.

Tool call:

{
  "name": "ScheduleWakeup",
  "input": {
    "delaySeconds": 300,
    "noop": true,
    "reason": "Waiting on three parallel Explore research agents (architecture/empirical, change-surface, risks) for the #526 plan; will resume once notifications arrive or check back in 5 min."
  }
}

Tool result (error):

Error: `prompt` is required when `stop` is not true.

The model then fell back to an unrelated Bash no-op call and continued waiting on the agent-completion notifications, which arrived normally — so the session recovered, but the ScheduleWakeup call itself was wasted.

Steps to Reproduce

  1. Start a session and run a skill (e.g. /investigate or any multi-step workflow) that spawns background subagents.
  2. Have the model call ScheduleWakeup with {"delaySeconds": <n>, "noop": true, "reason": "..."} (no prompt, no stop) while waiting on those agents, outside of an active /loop.
  3. Observe the validation error: ` prompt is required when stop is not true. `

Environment

  • Claude Code version: 2.1.237
  • Model: claude-sonnet-5
  • Entry point: CLI

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗