[BUG] Dynamic /loop (ScheduleWakeup) swallows the assistant's replies to the user — before AND after the tool call; only stopping the loop restores replies

Status Closed — duplicate
Reported on v2.1.233
Maintainer reply None cached
Activity 1 comment · opened Aug 16, 2026 · closed Aug 18, 2026

Summary

In /loop dynamic mode (ScheduleWakeup), the assistant's replies to the user are not shown to the user — both when the text is streamed BEFORE the ScheduleWakeup call in the same turn, and when the text is the LAST content of the turn AFTER the ScheduleWakeup call. The user sees the wake-up ticks but not the answers, and has to type "????" / "you are not responding" repeatedly. The only reliable fix was to stop the loop entirely (ScheduleWakeup stop:true), after which plain replies rendered again.

Related: #74184 (text hidden when a turn ends with ScheduleWakeup), #82634 (text in the same response as ScheduleWakeup destroyed), #67071 / #73561 (text between tool calls not rendered). This report adds: the "text AFTER the tool call, as final content" ordering also fails to reach the user while a dynamic loop is armed, and a user-visible workaround (stop the loop).

Environment

  • Claude Code CLI 2.1.233, macOS 26.5.1 (Apple Silicon)
  • Model: claude-fable-5 (Fable 5)
  • Session: long-running autonomous release loop, /loop dynamic mode (ScheduleWakeup with 5–20 min delays), several background Agent tasks and one background Bash task active. User reads on the mobile app and desktop app.

Repro (observed 2026-08-16, ~00:15–00:35 local)

  1. Start /loop (dynamic). Each turn ends with ScheduleWakeup { delaySeconds: 300–1200, prompt: <same loop prompt> }.
  2. User sends a question mid-loop ("where are we now").
  3. Assistant turn A: text (answer, ~20 lines) → ScheduleWakeup(...). User sees nothing.
  4. Assistant turn B (per the tool's own guidance that the answer must be the final text): ScheduleWakeup(...) → text (answer). User still sees nothing ("YOU ARE NOT RESPONDING ... STOP THE FUCKING LOOP IT IS EATING THE TEXT").
  5. Assistant calls ScheduleWakeup { stop: true } and replies with plain text, no tool calls. User sees it.

Session JSONL (available on request; contains private project data so not attached) shows the assistant text blocks persisted in both orderings, so this is a rendering/delivery issue, not a generation issue.

Expected

Assistant text in a turn is shown to the user regardless of whether a ScheduleWakeup (or any tool call) precedes or follows it in the same turn, and regardless of an armed dynamic loop.

Impact

Autonomous long-running sessions (the main use of /loop) become unusable for interaction: the operator cannot get answers without killing the loop, which also kills the automation. High severity for anyone running Claude Code as an operator harness.

View original on GitHub ↗

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