[Bug] GPT OSS 120B subagent stops mid-reasoning and returns empty result after several tool calls

[YoungJurry]

Description

When using GPT OSS 120B (OpenAI open-weight reasoning model, 117B) as a subagent via the task tool, the subagent executes tool calls correctly for several iterations, but then during a subsequent <think> reasoning step it stops abruptly and exits, returning an empty result to the orchestrator.

The subagent session log shows the model produced a valid text response after the tool calls, but the orchestrator receives an empty <task_result>.

Key observations:

• The subagent successfully calls tools (read, bash, edit, etc.) for the first 2-3 rounds
• During a subsequent reasoning (<think>) step, execution halts
• The orchestrator receives empty result
• The model's reasoning tokens may interfere with the subagent result capture, similar to the mechanism in Ollama subagent executes tool calls correctly but always returns empty text to orchestrator #18423

Plugins

opencode-dcp

OpenCode version

latest

Steps to reproduce

1. Configure GPT OSS 120B as a subagent (via openai-compatible provider or ollama)
2. From the main session, delegate a multi-step task via task tool to the GPT OSS 120B subagent
3. Let the subagent execute 2-3 tool calls (read files, run commands, etc.)
4. Observe that after the tools execute, during the model's next reasoning step, execution halts
5. The orchestrator receives empty/void result

Screenshot and/or share link

No response

Operating System

Linux

Terminal

No response

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Ollama subagent executes tool calls correctly but always returns empty text to orchestrator #18423: Ollama subagent executes tool calls correctly but always returns empty text to orchestrator — describes the same symptom (subagent returns empty result after tool calls) and may share the same root cause, just with a different model/provider.

[YoungJurry]

Note: this is intermittent — it does not reproduce 100% of the time, but has occurred multiple times. The number of tool calls and task complexity do not seem to correlate with whether the issue triggers.

[YoungJurry]

I gathered a more concrete local repro/evidence chain for this.

Environment:

• OpenCode 1.15.7
• Linux
• parent/orchestrator model: cliproxyapi/gpt-5.4 (variant: xhigh)
• affected subagents: @web-search and @Librarian
• both subagents use cliproxyapi/openai/gpt-oss-120b:free

What I can confirm locally:

1. The child session is really created and runs many steps/tools successfully.
2. In the failing case, the child does not necessarily crash with an explicit error.
3. Instead, the child can finish with a final assistant message whose finish is "stop" and error is null, but whose final message has no text part.
4. When that happens, the parent gets an empty task result / seemingly blank subagent outcome.

Concrete failing child session from my local DB/logs:

• child session: ses_1a2c251abffeHN7qqqbWOgQZjl
• title: Research DeepSeek V4 Pro variants (@web-search subagent)
• final assistant message: msg_e5d41dcd00018Vb3gFqx7Pc2e1
• message metadata:
  • role: assistant
  • finish: "stop"
  • error: null

But the final parts for that message were only:

• step-start
• reasoning
• step-finish

There was no final text part on that stop turn.

The last reasoning part from that final child message was:

We have gathered info: the API docs show "thinking": {"type":"enabled"} and "reasoning_effort":"high". It mentions non-think, think high, think max. Need to verify official docs page for max. The "Thinking Mode" guide probably lists low, high, max. Let's fetch that guide directly via r.jina.ai.

So from OpenCode's perspective, the child session completed a final assistant turn, but that turn contained reasoning only.

I also checked the current source path that explains why the parent becomes empty here:

packages/opencode/src/tool/task.ts

still does:

return result.parts.findLast((item) => item.type === "text")?.text ?? ""

That means a reasoning-only final assistant turn collapses to an empty string, which matches the observed parent-side symptom.

For contrast, I also have a successful sibling case with the same provider/model family:

• child session: ses_1a2eac1caffeF2bTo90QdyvxJc
• final assistant message: msg_e5d1834f9001Xicvc5VEPJ1JAi
• that one had:
  • finish: "stop"
  • a real text part
  • and the parent received a normal <task_result>

So this looks intermittent, but the failure mode is now much narrower:

• GPT OSS 120B via openai-compatible can sometimes end a subagent turn with reasoning-only output after tool use
• task.ts assumes the final useful payload is a text part
• if no text part exists, the orchestrator gets "" with no diagnostics

This seems related to both:

• #18423 (subagent executes tools but parent gets empty text)
• #24447 (TaskTool returns no diagnostic context when subagent result text is empty or missing)

At minimum, it would help if the parent received a diagnostic fallback when the child finishes without a text part, instead of an empty <task_result>.

[YoungJurry]

@nexxeln

like this

[github-actions]

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.