[BUG] /loop dynamic mode: user questions interjected into ScheduleWakeup turns get zero assistant text — model only re-runs checks and re-schedules (claude-fable-5)

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?

During a /loop dynamic-mode session (self-paced ScheduleWakeup, 270s interval, monitoring a long-running background process), the model stops emitting any assistant text. User questions typed during the loop are delivered into the wakeup turns (as queued messages), the model visibly reacts to them by running diagnostic tool calls — but every turn ends with only tool_use blocks + a new ScheduleWakeup call and zero text blocks. From the user's perspective the session is indistinguishable from a hung/broken session: questions like "why aren't you answering?" get no reply, three consecutive turns in a row.

This is not a rendering issue — I verified at the transcript (.jsonl) level that no text blocks are generated at all (details below). It looks like the model, once locked into the self-paced loop protocol ("re-pass the same /loop prompt via ScheduleWakeup each turn"), treats interjected user messages as part of the monitoring tick and skips the answer step entirely, going straight back to sleep.

Environment

• Claude Code CLI 2.1.175, macOS (darwin 25.5.0, Apple Silicon), terminal
• Model: claude-fable-5
• Permission mode: bypassPermissions
• Session state: /loop dynamic mode entered organically (model chose self-paced ScheduleWakeup with delaySeconds: 270 to monitor a background Bash task); one background shell running

Transcript-level evidence (session .jsonl, timestamps UTC; user prompts translated from Korean)

Once the model entered the wakeup loop (first ScheduleWakeup at 11:42:04), its last text block ever was at 11:42:51 (18 chars, a one-line status note). After that:

| Time (UTC) | User prompt | Assistant turn contents |
|---|---|---|
| 11:43:19 | "I thought it had stopped on an error — was it just waiting on monitoring?" | thinking(0ch) → Bash → ScheduleWakeup(270s) — no text |
| 11:45:45 | "Why aren't you answering?" | enqueued at 11:46:00 (queue-operation: enqueue), delivered as a queued_command attachment into the wakeup turn → thinking(0ch) → Bash ×2 → ScheduleWakeup(270s) — no text |
| 11:47:08 | "Are you in a state where you can't reply?" | thinking(0ch) → Bash → ScheduleWakeup(270s) — no text |

Whole-session stats: 5 user prompts, 32 tool_use blocks, 4 text blocks total — the last one at 11:42:51, right at loop entry; the three user questions after that got zero text. Every post-loop turn ends stop_reason: tool_use on the ScheduleWakeup call.

The ScheduleWakeup calls themselves are well-formed (same monitoring prompt re-passed verbatim, sensible reason strings reporting healthy progress) — so the loop mechanics work; it's the conversational reply that gets dropped.

Anecdotal model correlation: I've run the same kind of monitor-loop sessions on pre-Fable models (Opus/Sonnet) and interjected questions there did get text replies. I've only observed this total-silence pattern since switching to claude-fable-5. Sample size is small, so treat as a hint, not a conclusion.

Related (but distinct) issues

• #65108 — status updates not visible at wakeups: suspected rendering suppression; in my case the transcript proves the text is never generated, so this may be the same root cause manifesting model-side, or a different bug.
• #61718 — Cowork queued message never actioned (no follow-up turn at all); here the queued message is delivered and a turn does run — it just contains no text.
• #58235 / #64744 — ScheduleWakeup cancellation/persistence problems; different failure mode, but they compound this one: a loop that won't answer and keeps re-scheduling is effectively unrecoverable without killing the session.

What Should Happen?

1. A turn that contains a user text prompt should never end with only tool calls + ScheduleWakeup and zero assistant text. If the model ends such a turn with no text block, the harness should force a continuation (same way it nudges after empty responses) or at minimum surface a visible warning that the queued user message went unanswered.
2. Ideally the /loop dynamic-mode guidance (ScheduleWakeup tool description / system prompt) should explicitly instruct: when a user message was interjected since the last wakeup, answer it in text before calling ScheduleWakeup.

Error Messages/Logs

No errors. Turns complete "successfully" (stop_reason: tool_use on ScheduleWakeup), Stop hooks run normally. That's the problem — silent from the user's seat, healthy from the harness's.

Steps to Reproduce

1. Start a long-running background Bash task and ask Claude (claude-fable-5) to monitor it periodically; let it settle into a self-paced ScheduleWakeup loop (it picked 270s here, re-passing its monitoring prompt verbatim).
2. While it is between/within wakeup turns, type direct questions ("why aren't you answering?", "are you stuck?").
3. Observe: the questions are queued and delivered into wakeup turns; the model runs diagnostic tool calls in apparent reaction, then calls ScheduleWakeup again and the turn ends with no assistant text. Repeats indefinitely.
4. Recovery requires interrupting the session from the user side; the obvious in-band mitigation (explicitly instructing "answer my question in text before calling ScheduleWakeup") is plausible but was not tested before the session was abandoned.

---

🤖 Investigated and filed with Claude Code on the user's behalf (transcript analysis done in a separate session on the same machine).