Turn ends normally but the assistant message has no text block (only reasoning + tool-call)

[bxlelwx]

Summary

A turn completes normally (turn/end received) but the assistant/message event contains only reasoning and tool-call blocks — no text block at all. The client receives nothing to display, so the user sees "no reply" even though the turn finished successfully.

Environment

• DeepSeek Harness desktop 0.2.1-rc.2, Windows x64, nightly channel
• Model: deepseek-official/deepseek-flash, reasoning effort max
• Context plugin: billion-context 0.1.206
• Client: custom Node client driving session/prompt over the local API and consuming streamed session events

Event sequence observed

step/start → assistant/message → tool/call → tool/result → step/end → turn/end

The assistant/message blocks were:

["reasoning(N)|tool-call"]

No text block in any of them.

Frequency (single day, same session)

4 occurrences, all around :12 past the hour:

17:12:18  blocks=["reasoning(163)|tool-call"]
18:12:18  blocks=["reasoning(161)|tool-call"]
19:12:38  blocks=["reasoning(72)|tool-call"]
20:12:21  blocks=["reasoning(868)|tool-call"]

The first two coincide with an hourly proactive/silent wake — arguably fine there. The latter two happened during real conversation: the user had just asked a question and expected a reply; the tool call was followed by no text.

Expected behavior

1. If a turn intentionally ends after tool calls without prose, it would help if that state were distinguishable (e.g. a flag on turn/end, or an explicit empty text block), so clients do not treat it as a lost message.
2. If it happens while a reply is expected, a continuation nudge before turn/end (or a visible warning in the events/log) would help.

Notes

• No HTTP errors, no stream interruption, no corrupt session log.
• billion-context's "degenerate turn" detection did not trigger, because the event sequence looks complete from the client's perspective.
• Other turns in the same session are fine.

Question

Is assistant/message with only reasoning + tool-call followed by turn/end an expected path? If not, is this a known issue — the r0.2.1-rc.3 (2026-10-23) release notes don't mention it.

[bxlelwx]

补充一条观察：四次「回合结束但无正文」都落在整点后 12 分钟附近 —— 17:12:18、18:12:18、19:12:38、20:12:21。同一天、同一会话、间隔正好一小时。

不像用户操作引起的随机退化，更像是和某个每小时触发的定时任务撞上了（本机装了 dsh-proactive，每小时一次；时间点是否巧合，我无法从会话日志里进一步确认）。

前三次 reasoning 块是 163/161/72 token，第四次 868 token —— 第四次的思考反而最完整，仍然没吐正文。

[dgesteves]

Yes, that's an expected path, and the :12 pattern points at dsh-proactive.

The loop ends a turn right after a tool batch, with no further model step and no text, when a tool result is marked concludesTurn; turn/end then has reason.kind: 'completed' (agent.ts, dsh-v0.2.1-rc.2). Without that marker the loop always opens another step/start after tool/result. dsh-proactive's proactive_reclaim sets it: on a wake that needs no message the model is told to call it "as your ONLY action with no chat text", and it calls exec.concludeTurn() (tools.ts). That's your reasoning | tool-call → tool/result → step/end → turn/end.

So the flag you're after is already in the events. Check the name of the tool-call block in those four messages. If it's proactive_reclaim and its tool/result isn't an error, the turn was a deliberate silent wake, not a lost reply. concludesTurn isn't written to tool/result, so the tool name is the signal.

For the 19:12 and 20:12 ones: proactive_reclaim returns an invalid_action error outside an active wake, so if those calls succeeded, they were heartbeat turns that fired just after the user's question. To keep the heartbeat out of a live conversation, give that alarm a min_idle_seconds (e.g. 900). The wake then waits until the session has been quiet that long (README). proactive_update replaces the whole spec, so pass the existing trigger and prompt again.

If you'd rather force a reply, a plugin can listen to agent/turn-stopping and call agent.steer(...). The loop awaits it before closing every turn, concluded ones included (agent.ts).

I traced this in the rc.2 source and dsh-proactive 0.3.2 but haven't run your session.

[argszero]

To add the half the answer above does not cover: dgesteves' reading explains all four events you logged — a tool batch that concluded the turn on purpose, which you can confirm by the tool-call block's name (proactive_reclaim).

The shape that carries no signal at all is the neighbouring one: the model stops after streaming reasoning, with no text block and no tool call. Nothing objects there either — a reasoning block counts as content, and the provider-neutral EMPTY_RESPONSE code is raised only for a response with no content blocks at all — so the turn settles completed with an empty assistant/message. That is your expected-behaviour item 2, and it can be covered from a plugin instead of the core.

@argszero/dsh-silent-completion-guard 0.1.0 — https://github.com/argszero/dsh-silent-completion-guard

dsh plugin --profile <profile> add github:argszero/dsh-silent-completion-guard

It wraps the llm/stream response the loop consumes and rewrites only the terminal frame of a qualifying attempt — finish{reason:{kind:'stop'}} becomes finish{reason:{kind:'error',failure:{code:'EMPTY_RESPONSE'}}} — so the loop takes its existing error branch: the retry policy decides whether to repeat the request, and an exhausted budget fails the turn loudly with the reason named. It fires only when the terminal reason is stop, at least one reasoning block streamed, no visible text streamed, and no tool call streamed or completed, so an attempt that did produce a tool call is passed through chunk for chunk and none of your concludesTurn turns are affected. One install note: installing alone is inert — the bundle also has to be listed under dsh.profile.bundles, which dsh plugin add writes for you.