Assistant message text hidden when a turn ends with ScheduleWakeup

Bug report: assistant message text hidden when a turn ends with ScheduleWakeup

Component: Claude Desktop app (Windows 11 Pro 10.0.26200), Claude Code session UI
Severity: High (silent loss of assistant output — user believes the assistant is unresponsive)

Summary

When an assistant turn contains message text followed by a ScheduleWakeup tool
call (the self-pacing mechanism used by the /loop skill), the desktop client
renders the entire turn as a collapsed "Used ScheduleWakeup ›" chip. The text
written before the tool call is not displayed anywhere the user can see.

Impact observed

During a long-running self-paced /loop session (~24h), roughly a dozen
substantive assistant replies (study results, summaries, direct answers to user
questions) were invisible to the user. The user repeatedly asked "why aren't
you talking to me" / "stop ignoring me" while the transcript (from the model's
side) contained full replies. Diagnosis was confirmed by sending a text-only
turn with no tool calls, which the user could see immediately, after which the
user confirmed: "yes I can see this. I did not see the others."

Repro

1. Start a self-paced loop (/loop <prompt> with no interval) so the model

ends turns with ScheduleWakeup per the skill instructions.

1. Have the model write a normal multi-paragraph reply and then call

ScheduleWakeup as the last action of the turn (exactly as the /loop skill
instructs: "Briefly confirm ... then, as the last action of this turn,
call ScheduleWakeup").

1. Observe the client: the turn shows only the collapsed tool chip; the reply

text above it is not rendered.

Expected

Message text in a turn should render regardless of a trailing tool call — or,
if tool-terminated turns are intentionally collapsed, the text portion should
still be shown above the chip.

Notes

• The /loop skill's own instructions direct the model to put its user-facing

confirmation BEFORE the ScheduleWakeup call in the same turn, so the skill
design and the client rendering are in direct conflict.

• Workaround adopted: deliver content in text-only turns and schedule wakeups

in separate content-free turns (or rely on task notifications), but this is
discoverable only after the user has already lost messages.