/loop skill has no cancel mechanism — loops run until session ends

Status Closed — not planned

Maintainer reply None cached

Activity 5 comments · opened Apr 1, 2026 · closed May 31, 2026

The /loop skill starts a recurring prompt on an interval but provides no way to cancel it from within the session. Once started, it fires indefinitely until the session is terminated.

Expected behavior: A /loop cancel or /loop stop command that terminates the active loop, or the loop should automatically stop when the agent responds with a terminal acknowledgment.

Actual behavior: The loop runs forever. There is no cancel command. TaskStop doesn't work because the loop doesn't run as a trackable background task. The process isn't visible as a shell process that can be killed.

Impact: In long-running sessions, a loop set for an early task continues firing hundreds of times after the task is complete. Each firing generates a response, wasting tokens and polluting the conversation. The agent cannot stop it — only the user can by ending the session.

Workaround: Don't use /loop. Use sleep N && echo "message" with run_in_background: true for one-shot timers instead. The agent must consciously set each subsequent timer, making the stop condition naturally enforceable.

View original on GitHub ↗

5 Comments

tedjames · 5 months ago

Yeah, I'm also experiencing this as well. It's a huge problem. Would appreciate some support on this.

0xbrainkid · 5 months ago

This is control-loss at the persistent-loop boundary.

If /loop has no cancel mechanism and runs until the session ends, then the system is creating ongoing execution without providing a first-class operator control to stop it inside the same workflow surface.

Why it matters:

any persistent or repeating automation needs an equally accessible stop path
forcing users to end the whole session just to stop one loop collapses granularity of control and increases collateral disruption
once a loop is active without a bounded cancel path, trust in long-running automation drops because users cannot safely experiment or recover midstream

I would want clarity on:

whether /loop currently lacks a control primitive entirely or whether the stop path exists but is not exposed consistently
whether loops are tracked as addressable runtime objects that can be paused/stopped, or merely embedded in session flow with no separate lifecycle handle
whether the product can expose explicit cancel/pause/status controls before adding more loop-like automation patterns

Long-running automation needs symmetric control. If /loop can start from the chat surface but only stop by killing the session, the operator boundary is not strong enough.

github-actions[bot] · 4 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

snailwei · 3 months ago

still not implemented, I have to type /loop cancel, after a LLM round-trip, the LLM cancel it.

tekn0x · 1 month ago

Is there still not a proper solution or best practice for this?

/loop skill has no cancel mechanism — loops run until session ends

5 Comments

Related Claude Code issues

Browse by topic