Turn silently ends as "completed" when the final step contains only reasoning blocks

[tuan18495]

Turn silently ends as "completed" when the final step contains only reasoning blocks

Repo: deepseek-ai/deepseek-harness (reported via GitHub Discussions, as CONTRIBUTING.md asks)
Packages: @deepseek-ai/dsh-agent-loop 0.2.1-rc.2 (packages/core/agent-loop), @deepseek-ai/dsh-llm-pi-ai 0.2.1-rc.2 (packages/llm/llm-pi-ai)
App: DeepSeek Harness Desktop (@deepseek-ai/dsh-desktop 0.2.1-rc.2), macOS arm64

Summary

When a model step finishes with stop and its content contains only reasoning blocks (no text, no tool call), the agent loop records the turn as completed and goes idle. The user sees the agent "stop by itself" mid-task, with an empty final answer, and has to send another message to make it continue.
Typical trigger: a reasoning model that "announces" its next action inside its reasoning ("Let me apply the edit.") and ends the response without emitting the tool call. Observed in real sessions with opencode-go/deepseek-v4.1-flash (reasoningEffort max) via an OpenAI-Responses-compatible provider; in two of those cases the reasoning text even ends with DeepSeek's raw DSML tool-call markup (</｜｜DSML｜｜ parameter>), i.e. the tool call leaked into reasoning instead of being emitted as a function call.

Root cause

1. dsh-llm-pi-ai mapStopReason only treats a stop with zero content blocks as EMPTY_RESPONSE. A message with reasoning blocks only passes as a normal { kind: "stop" }:

case "stop":
  if (message.content.length === 0) return { kind: "error", failure: { code: EMPTY_RESPONSE_CODE, ... } };
  return { kind: "stop" };

2. dsh-agent-loop step handling then ends the turn because there are no tool calls:

const toolCalls = message.content.filter((block) => block.type === "tool-call");
if (toolCalls.length === 0) return { kind: "completed" };

So "no user-visible output and no action" is indistinguishable from "model finished the task".

Evidence from local sessions

Scanned all local sessions (~/.dsh/sessions/**/session.v4.jsonl.zstd):

• 71 turn/end with reason.kind = completed; 3 of them end on an assistant message whose content is [reasoning] only, with finish.reason = stop / stopReason: "stop".
• All 3 were followed by the user complaining that the agent stopped mid-task (e.g. "Why does it keep stopping while working?").
• Of 1,094 assistant steps that contained a tool call, 0 matched the "reasoning only" pattern, so the condition is a precise signal.

Reproduction (deterministic)

fault-proxy.mjs (attached) is a small proxy in front of any OpenAI-Responses endpoint. For the first /v1/responses request it strips every message / function_call item and the output_text / content_part events from the SSE stream, keeping only the reasoning item. All later requests are forwarded unchanged.

1. node fault-proxy.mjs (listens on 127.0.0.1:4011, forwards to 127.0.0.1:4000).
2. Point a dsh-llm-pi-ai provider (api: openai-responses) at http://127.0.0.1:4011/v1, using a reasoning model.
3. dsh --profile <headless-profile> --json "Create file a.txt containing 1, then report done."
   Actual: 1 step, turn_end reason completed, {"type":"final","text":""}, and a.txt is not created.
   Expected: the loop treats an action-less, text-less stop as an incomplete step and continues, or surfaces it as a retryable error.

Workaround that works (local plugin)

A small plugin listening on agent/turn-stopping: if the last assistant message of the turn has no tool-call and no non-empty text, it calls agent.steer(...) with a continue reminder (source.kind: "stall-guard", form: "notice"), at most 2 times per turn. With the same fault proxy, the run continues to step 5, creates a.txt, and returns a proper final answer.

Suggested fixes (any one of these)

• In mapStopReason, treat stop with no text and no tool-call blocks (reasoning only) like EMPTY_RESPONSE, so the existing retry policy applies.
• Or, in the agent loop, end a turn as completed only if the last message has visible text. A reasoning-only stop should trigger one bounded "continue" step, or a distinct turn-end reason so the UI can show "model stopped without answering" with a Continue button.
• Optionally, detect leaked DSML tool-call markup in reasoning for DeepSeek models and recover it as a tool call.

fault-proxy.txt

[PerryLink]

Both cited lines are real on 0.2.1-rc.2, and the second one is the reason this is worth fixing in the loop rather than in the adapter.

packages/llm/llm-pi-ai/src/stream.ts, inside mapStopReason (:80):

:99        if (message.content.length === 0) {
:104             code: EMPTY_RESPONSE_CODE,

packages/core/agent-loop/src/agent.ts:

:550        if (toolCalls.length === 0) return { kind: 'completed' }

The architectural point. :550 does not look at the content at all — it decides "the turn is over" purely from the absence of tool calls. So the condition you found is not a coincidence of one adapter: any adapter that reports stop with a content list that contains no tool call lands here, and the only thing that separates your three bad turns from the sixty-eight good ones is that the good ones also produced text. That makes the missing predicate "no tool call and no visible text", not "no tool call".

That matters for where to patch. Fixing :99 to test for visible text covers pi-ai routes only. Fixing :550 — or the step-end mapping that feeds it — covers every provider, including the ones whose adapters map their stop reasons differently. If the maintainer prefers the narrow change, :99 is the smaller diff; but the report is stronger if it says plainly that the loop is content-blind and the adapter is where the symptom surfaces.

One more thing to name. The EMPTY_RESPONSE that :99 already produces when content is empty is retryable, so the machinery for "this step produced nothing, try again" already exists and is already reachable — you are arguing that reasoning-only content should join that same path. Framing it as "extend an existing condition" is much easier to accept than "add a new guard", and it also answers the obvious pushback ("what if the model legitimately stops after thinking?") without any new policy: a turn with no visible output and no action is treated exactly as the empty one is today.

Your workaround also confirms the seam, which is worth a sentence in the report: agent/turn-stopping is dispatched at agent.ts:362, so a plugin can observe the turn end and steer. That means the platform already exposes enough to detect the condition — the only thing missing is that core does not act on it.