[BUG] Main agent using /loop to wait for
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?
Claude code is using /loop to wait for subagents. If the subagent finishes and the user is AFK, it will repeat the prompt. Usually this is caught as a repeat but it is (a) wasteful, (b) risks unexpected behaviour if the agent doesn't recognise it as a repeat.
For a long process this may trigger multiple time, injecting the prompt with the agent is working.
Appears as:
> Prompt that triggers one or more subagents
● Doing work
● 2 background agents launched (↓ to manage)
├ Agent (XXX)
└ Explore (YYY)
● Both subagents are running in the background. I'll wait for their results before proceeding to ZZZ.
● Waiting for the two subagents to complete.
✻ Crunched for 2m 39s
● Agent "XXX" finished · 1m 26s
● Reponse about result
● Waiting on the YYY agent.
✻ Cooked for 8s
● Agent "YYY" finished · 3m 46s
● Both subagents are back with ZZZ. Something about the result.
Read 2 files
● Analysis of agents
✻ Brewed for 24m 49
# Here is a user prompt but user is AFK
✻ Claude resuming /loop wakeup (Jul 4 10:10am
> Prompt that triggers one or more subagents # This is not triggered by the user
● The prompt that triggers one or more subagents already ran to completion in this session — re-running it would do the work again.What Should Happen?
It should not use /loop to wait for subagents
Error Messages/Logs
Steps to Reproduce
Wait for a subagent. Be unlucky.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.200
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Asking Opus to reflect on it:
❯ What caused this "resuming /loop wakeup"? There shouldn't be a loop running.
The ScheduleWakeup calls I made. There is no /loop running — I created the effect myself.
While waiting on the background subagents (XXX), I used ScheduleWakeup as a fallback timer, and passed the /XXX … slash command back as its prompt. ScheduleWakeup is the dynamic-/loop mechanism: each firing re-invokes whatever prompt it carries. So each wakeup re-entered the skill — that's the "resuming /loop wakeup" you saw.
That was the wrong tool for the job. The harness already re-invokes me automatically via task-notification when a tracked background agent finishes, so the timers were redundant. The last one I armed (a 90s fallback before the commit step) fired after the work was already committed, which re-triggered the skill and produced the spurious "already complete" re-run.
Nothing is still pending: my previous turn did not arm a new wakeup, and ScheduleWakeup fires once per call rather than repeating. So no further re-invocations will occur. My mistake was polling with wakeups instead of just letting the completion notifications drive the waits.