[BUG] Dispatch stuck in infinite self-loop: system repeatedly injects "[Your previous response had no visible output]" after long context

🔁 Second Occurrence — 2026-07-04 (same day, different session)

The bug occurred again today with new and more severe symptoms not present in the original report.

New symptom 1: /clear blocked during loop

During the infinite loop, the user attempted to send /clear in multiple ways:

• Typed "請發 /clear" (please send /clear)
• Typed "👆 /clear"
• Typed "."

None were processed normally — the system appeared locked, preventing normal message delivery while looping.

New symptom 2: /clear does NOT fully stop the loop

After /clear eventually executed, the user asked a new question. Dispatch responded with 3 identical duplicate messages in a row:

回來了！重開機一切都好嗎？有什麼要繼續的？ 回來了！重開機一切都好嗎？有什麼要繼續的？ 回來了！重開機一切都好嗎？有什麼要繼續的？

This confirms that /clear does not reliably terminate the loop — the duplicate-response behavior persists into the new context window.

New symptom 3: "no visible output" false positives continue after /clear

After /clear, the system continued injecting [Your previous response had no visible output] even though SendUserMessage had already been called and the user received the message. This pressured Dispatch into sending more duplicate responses in the fresh session.

Comparison table

| Finding | First occurrence | Second occurrence |
|---|---|---|
| Trigger | Long context | Same (new session, same day) |
| /clear effectiveness | Untested (mixed into text) | Partially — duplicates persist |
| Post-/clear behavior | — | 3× identical duplicate responses on first reply |
| "no visible output" false positives | Yes | Yes, continues after /clear |
| Input accepted during loop | Unknown | No — input appears blocked |

Environment

• Date: 2026-07-04
• Platform: iOS Dispatch app (Claude mobile)
• macOS host: same as original report

Root cause, from string-inspecting the compiled Claude Code bundle (v2.1.202). Full derivation in #70422; summary tailored to the Cowork/Dispatch case here.

The nudge is not triggered by "a turn ending in a tool call." A turn whose final action is a tool call (including SendUserMessage) has stop_reason: "tool_use" and is explicitly excluded. The injection fires only when all of:

• stop_reason is end_turn or stop_sequence (turn ended with no pending tool call), and
• the turn has no non-empty text block (content.some(b => b.type === "text" && b.text.trim().length > 0) is false), and
• it hasn't already nudged this cycle.

Telemetry name query_thinking_only_response, state flag thinkingOnlyNudged — the detector targets thinking-only end-turns ("the model thought, then ended without saying anything").

Why Cowork/Dispatch loops: the user-facing channel there is the SendUserMessage tool, which emits no text block. After delivering via SendUserMessage, the model ends the turn thinking-only -> no text block -> nudge fires -> the system prompt re-reads "produce visible output" as "call SendUserMessage again" -> resend loop.

Note on the common description in these reports ("every turn ending with a tool call triggers it"): that isn't quite the mechanism — the tool-call turn itself is excluded; the nudge lands on the following thinking-only turn.

Why plain text breaks it (matching the known workaround): any non-empty text block makes the text check true, so the condition cannot fire that turn.

Suggested fix: treat a turn as having visible output when it delivered user-facing content via a tool (notably SendUserMessage), not only when a non-empty text block is present.

I was able to get my instance of claude to spit out some sort of bug report on its end.

Cowork Rendering Bug Report — Persistent "\[No Visible Output]" Loop
Date: 2026-07-13
Environment: Cowork mode (Dispatch), iPad client
Model: claude-opus-4-6

\---

Summary

The system repeatedly injects \[Your previous response had no visible output. Please continue and produce a user-visible response.] after every SendUserMessage call, despite every call returning "Message delivered to user." This creates an infinite loop where the assistant keeps re-sending messages, flooding the user.

Impact

• The user received 12+ duplicate messages about a single question (confirmed by user)
• The assistant cannot break the cycle from its side — only a real user message interrupts the loop
• Massive context window waste as the assistant responds to each false negative
• Poor user experience due to message spam

Reproduction

This bug has occurred across two separate sessions (before and after context compaction). The behavior is:

1. Assistant calls SendUserMessage with valid content
2. Tool returns "Message delivered to user."
3. System immediately injects \[Your previous response had no visible output. Please continue and produce a user-visible response.] as the next human turn
4. Assistant responds with another SendUserMessage
5. Loop repeats indefinitely until the actual user sends a real message

What was tried (all produced the same false negative)

• Standard SendUserMessage with long-form content
• SendUserMessage with short content (single word, emoji, single character)
• SendUserMessage with file attachments (markdown file)
• mcp\_\_visualize\_\_show\_widget (elicitation form widget)
• mcp\_\_cowork\_\_create\_artifact (permission denied, but attempted)
• Writing files to outputs directory
• Various message lengths from 1 character to \~2000 characters

None of these approaches stopped the false negative system message from appearing.

User confirmation that messages ARE arriving

The user sent an iPad screenshot (IMG\_0107.png) in the prior context window proving that messages were rendering on their device. The user also explicitly said: "BTW you sent me 12+ messages about the eyedropper just now" — confirming delivery while the system continued to claim nothing was visible.

Suspected cause

The \[Your previous response had no visible output] system injection appears to fire before the SendUserMessage content finishes rendering on the client, or the rendering confirmation signal is not being received by the system that generates this injection. The check appears to be evaluating whether the assistant produced "visible output" in the response body (plain text outside of tool calls) rather than checking whether SendUserMessage was called successfully.

Suggested fix

The "\[no visible output]" check should treat a successful SendUserMessage call (with "Message delivered to user." result) as visible output. In Dispatch/Cowork mode, SendUserMessage IS the output mechanism — plain text assistant responses are explicitly documented as not rendered to users. The system is enforcing a visibility check that contradicts the documented output model.

Session details

• Session path: /sessions/confident-blissful-maxwell
• This occurred continuously for 30+ system turns in a single session
• The loop only broke when a real user message arrived via the system-reminder inline mechanism

Happening to me as well

EDIT: Dispatch is basically unusable for me because this happens all the time

This just happened to me twice, after just having started a new Claude Dispatch conversation, so the conversation was really short. Poor Claude sends the same message, slightly paraphrased, three times, because it received [no visible output] form its harness.

Claude Desktop for Windows version 1.22209.0 (latest available as of today 2026-07-20)