[Bug]: A reasoning-only turn ends with zero visible output — run button clears, chat stays empty, no notice (looks like a silent stop)

[zhe97396-tech]

Summary

On long sessions, a turn can complete successfully on the agent side and yet produce zero visible output in the chat: the assistant reply never shows up, the run/abort button clears, nothing scrolls, and there is no toast or notice of any kind. From the user's seat the agent looks like it silently stopped/crashed, so the natural reaction is to re-prompt ("怎么停了，继续" / "怎么又断了") — and the agent's next turn then confirms the previous turn had already finished.

Trigger (visible in the agent log, not in the UI):

agent.conversation_loop: Reasoning-only clean stop (99856 chars) — returning the reasoning as the final response
agent.conversation_loop: Turn ended: reason=text_response(finish_reason=stop) ...

i.e. the model returned reasoning with no content, Hermes promotes the reasoning to the final response and ends the turn — but that promoted response is not surfaced in Studio as a message. Because the turn did end, the UI is behaving "correctly" by clearing the running state; the bug is that a completed turn can leave the chat with nothing in it and no explanation.

Measured on one real session: 6 of 71 turns (8.5%) ended with zero visible assistant text, 4 of them after 2–9 minutes of tool work.

Environment

• Ekko Studio 0.7.23 (Windows desktop build, bundled webui; server webui/dist/server, agent bridge webui/dist/server/agent-bridge/python)
• Hermes Agent 0.21.3 (2026.9.14, upstream c5452725), local gateway, Studio API 127.0.0.1:8648
• Model deepseek/deepseek-v4.1-flash via provider: custom:commandcode (api.commandcode.ai), agent.reasoning_effort: medium, approvals.mode: manual
• Affected session mu8jf5ck1n2koq (1099 messages, ~400–600K token context, archived) — the same behaviour was reproduced across many turns on 09-20 and 09-21

Steps to reproduce

1. Use a long session (this one was ~400–600K tokens) on a reasoning model that sometimes finishes a turn with reasoning but no content (deepseek-v4.1-flash behind a custom provider).
2. Send a normal message and let the turn run (tools + a few minutes).
3. When the model returns reasoning-only, the agent log prints Reasoning-only clean stop (N chars) — returning the reasoning as the final response followed by Turn ended: reason=text_response(finish_reason=stop).
4. Observe the UI: the run button disappears, the chat receives no new message, nothing scrolls, no notice. The text (if visible at all) is only inside the collapsed thinking block.
5. Send any follow-up prompt: the answer confirms the previous turn had completed, i.e. nothing was actually lost.

Evidence

Agent log (11 occurrences in this one session, 2026-09-20 → 2026-09-21):

2026-09-20 20:47:14 WARNING Reasoning-only clean stop (99856 chars) — returning the reasoning as the final response
2026-09-21 09:31:20 WARNING Reasoning-only clean stop (2481 chars)  — ...
2026-09-21 09:39:42 WARNING Reasoning-only clean stop (6975 chars)  — ...
2026-09-21 09:41:03 WARNING Reasoning-only clean stop (8835 chars)  — ...
2026-09-21 09:45:17 WARNING Reasoning-only clean stop (5023 chars)  — ...
2026-09-21 17:12:43 WARNING Reasoning-only clean stop (40551 chars) — ...
2026-09-21 17:26:44 WARNING Reasoning-only clean stop (4228 chars)  — ...
2026-09-21 17:29:57 WARNING Reasoning-only clean stop (895 chars)   — ...

1:1 correlation with the user's reports (log end time → next user message):

reasoning-only turn ended	user's next message
09-20 20:47:14	20:48:32 「怎么停了，继续」
09-21 09:31:20	09:33:14 「什么情况啊，怎么又断了，总是断是什么情况」
09-21 09:41:03	09:43:14 「？连查个原因也会中断、没法用了是吗」
09-21 17:26:44 / 17:29:57	17:29:29 「我就想确认一下，这个断断续续的问题是bug吗？我真的要崩溃了」

The agent's own next-turn reasoning (2026-09-20 20:48:59, verbatim from the session store):

「老板说"怎么停了，继续" —— 他以为我停了。实际上我上一轮已经完成了：tech-lead 样板落地 + 验证…」

Studio session store (read-only copy of hermes-web-ui.db) — the turn at 09:23:06 → 09:31:20:

09-21 09:30:47 assistant  content=0      reasoning=2343  finish_reason=tool_calls
09-21 09:30:52 tool       content=405    (execute_code result)
09-21 09:33:14 user       「什么情况啊，怎么又断了…」        ← next row

There is no assistant row for the promoted final response — the turn's last state is a tool result, then the user's next message. Session-wide the assistant rows are only finish_reason='tool_calls' with empty content (454 rows, reasoning carriers) or finish_reason=NULL with text (117 rows); no finish_reason='stop' row exists at all. The reasoning text of such a turn (e.g. the phrase 「第三次超时被拦」) is found only in the reasoning column — 0 hits in content.

Where it breaks (needs your call on ownership)

The promoted reasoning reaches the client as reasoning/thinking, not as message text, and thinking is collapsed by default in the UI (see #2937) — so the reply is invisible and the turn ends with an empty chat pane. Two layers could own this:

1. Bridge (webui/dist/server/agent-bridge/python): the final flush for a turn whose response came from the reasoning channel should emit it as a normal assistant message (message.delta + final assistant content), not only as reasoning.
2. Client: if the final answer is delivered as reasoning, either render it as the reply or don't silently clear the running state — show "本轮无正文回复（内容在思考中）" and/or auto-expand the thinking block.

I can't tell from outside which layer dropped/mis-labelled it — that's why I'm filing instead of patching.

Expected behavior

Either:

1. Render the promoted reasoning as the assistant reply (it is the reply — the agent considers the turn complete), or
2. If it is intentionally treated as thinking, then surface that: keep a visible signal that the turn ended without a text reply, e.g. a notice and/or auto-expanding the thinking block — instead of ending with an empty chat and a disappearing run button.

Notes

• No data loss: the work is done and the text is in the agent history; only the Studio representation is missing. A follow-up prompt makes the agent restate it.
• More likely on very long sessions: this session had ~400–600K token context, per-turn compression and 40 message-alternation repairs per request; the reasoning-only stops concentrated there. Starting a fresh session reduces the frequency but does not remove it.
• Aggravating factors — separate issues, not this bug (mentioning so they don't get conflated): in the same profile's log, Streaming failed before delivery: Connection error. ×149, Provider unavailable (timeout) auto-recovery with 16s/32s/60s backoff, and approval waits (bridge caps at 120s; the protected-file gate waited 300.05s on 09-21 09:29:59 with approval prompt timed out without a user response).
• Related issues: reasoning_effort: medium + 自定义 Provider 导致出完结果后持续"思考中"不停止 #2333 (same trigger — reasoning_effort: medium + custom provider + deepseek, opposite symptom: stuck "thinking" after the answer; open since 2026-08-03, no replies yet, workaround reported there is clearing agent.reasoning_effort), [Bug]: reasoning 缓冲跨 turn.boundary 累加 → 单条消息思考内容膨胀到 67 万字符，会话打开即卡死（渲染进程 165% CPU） #3141 (reasoning buffer bloat across turn boundaries — the 99856-char reasoning-only stop above is likely the same root), Bug: Auto-play TTS reads 'thinking' content that is collapsed by default in the UI #2937 (thinking content collapsed by default), Tracking: Chat execution UX, context observability, and command controls #672 (chat execution UX tracking), [Bug]: Tool approvals / clarifications / abort / queue edits are rejected with "Profile \"X\" is not available on this connection" on cross-profile sessions #3148 (unrelated but adjacent: same "run looks dead, user must re-prompt" class of confusion).

[samvallad33]

Reasoning-only turns that end with zero visible output and a cleared run button look like a silent stop. Users assume the agent quit while the real miss never surfaced. Would an explicit empty-output notice beat a blank chat when reasoning produces no visible token?