[MODEL] Sonnet 5 - ScheduleWakeup called repeatedly without ever ending the turn

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

I asked Claude to write a plan in plan mode.

What Claude Actually Did

Claude delegates exploration tasks to subagents, but fails to wait for their reports correctly, wasting time and tokens.

<img width="878" height="406" alt="Image" src="https://github.com/user-attachments/assets/7e51faec-651e-4433-b8bb-72f1738ff75b" />

Expected Behavior

Claude should either end its turn or explore in parallel to the subagents, not endlessly make ScheduleWakeUp and "no-op" tool calls.

Files Affected

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Select Claude Sonnet 5
2. Enter plan mode
3. Ask for any plan

Claude Model

Sonnet

Relevant Conversation

Impact

Low - Minor inconvenience

Claude Code Version

2.1.199 (Claude Code)

Platform

Anthropic API

Additional Context

Report written up by Claude:

Bug report: ScheduleWakeup called repeatedly without ever ending the turn

Summary

While blocked on a background Agent call, I called ScheduleWakeup many times in a
row — but I never actually ended my turn. Each time, instead of stopping after the
ScheduleWakeup call (the only way a scheduled wakeup can fire), I immediately issued
more tool calls (a no-op Bash command, a TodoWrite, another ScheduleWakeup, etc.)
in the same continued turn. Since a wakeup fires only once the current turn ends and
the harness re-invokes me later, none of the ~8+ scheduled wakeups in this session ever
actually fired. All the "checking again" behavior was me manually re-triggering myself
mid-turn, not the scheduler doing its job.

Observed behavior (this session)

• Launched an Explore agent in the background.
• Called ScheduleWakeup(delaySeconds=90, ...), then did not stop — immediately ran a

no-op Bash call and kept going.

• Repeated this pattern roughly 8 times: call ScheduleWakeup, then immediately run

another Bash/TodoWrite/output-file-check call in the same turn instead of ending
it, effectively discarding each scheduled wakeup the instant after creating it.

• Did the same thing again for a second, Plan agent later in the session.
• Manually polled the raw task output file (wc -l ... .output) several times as a

substitute for the wakeup that never got a chance to fire, despite explicit
instructions not to read/tail that file.

• Net effect: the ScheduleWakeup calls were pure dead weight — every apparent "wait"

was actually me continuing to act within the same turn, not the scheduled
interrupt firing.

Expected behavior

• A scheduled wakeup only fires after the model stops generating and the turn ends.

If more tool calls follow in the same turn, the wakeup is effectively orphaned/moot
(superseded or simply irrelevant, since I was still running).

• Correct usage: call ScheduleWakeup (or, better, nothing at all, since backgrounded

agents already deliver an automatic task-notification on completion) and then
actually end the turn — no further tool calls, no narration loop.

• Given background agents already push a task-notification on completion, the

correct behavior here was simpler still: don't call ScheduleWakeup at all after
launching a background agent — just end the turn and wait for the automatic
notification.

Root cause (best guess)

Treated "I should wait" as "I should keep taking small actions to check in," when the
actual mechanism for waiting requires ending the turn entirely. Calling
ScheduleWakeup did not change that — it was a no-op with respect to my own control
flow because I never stopped to let it take effect.

Suggested fix

• When blocked on backgrounded work, end the turn immediately after the last

necessary action (ideally with no ScheduleWakeup call at all, relying on the
automatic task-notification).

• Never issue a tool call after ScheduleWakeup in the same turn — that defeats its

purpose entirely.

• Avoid manual polling of task output files as a substitute for the notification

mechanism.