[Bug] opencode-go qwen3.7-plus: responses silently corrupted on the output side — leading paragraph lost, finish_reason=stop

Description

When using the opencode-go channel with qwen3.7-plus, responses are
intermittently corrupted on the output side: the request completes normally
(finish_reason=stop, token usage consistent with the surviving text), but the
beginning of the assistant reply is missing. The surviving text starts
mid-sentence, usually with an orphaned code-fence backtick.

We observed 6 corrupted messages across 2 independent client sessions on
2026-09-03 21:15 – 2026-09-04 00:52 GMT+8. Both clients are plain
OpenAI-compatible chat frontends (no agentic framework) talking to opencode-go,
so the corruption is not client-side rendering.

Observed patterns:

• The opening paragraph of the reply is cut off; the stored text begins with an
  isolated ` backtick followed by a half-sentence
  (e.g. a reply that should have started with "```bash" survives only
  from mid-table onward)
• In the worst case the entire "reply" was a JSON dump of the conversation
  history instead of an actual response
• The reasoning field of every corrupted message contains only debris —
  "…", \"...\", \"|\\n\\n\" — which looks like traces of a broken
  think-block/reasoning split
• finish_reason=stop on every one of them; no error surfaced anywhere

Timing / control group:

• Intermittent: the same model produced many normal replies the same evening
• After switching to a different provider/model later that night, zero
  recurrence across dozens of replies since

Suspected area: the think-block / reasoning-stream stripping logic
swallowing the opening ``` fence of the actual content. Supporting
evidence: the reasoning-field debris above, and that most corrupted replies
would plausibly have opened with a fenced code block.

This looks related to but distinct from:

• #46561 (open) — content-inspection false positives on the same
  opencode-go + Qwen channel, but on the input side (explicit 400); ours is
  output side, silent success
• #46094 (closed) — every reasoning delta appended as an empty reasoning part;
  same area (reasoning stream handling), recently fixed, so this may be a
  residual issue in that code path
• The 2026-09-01 changelog entry: "Removed built-in Qwen sampling defaults that
  could send unsupported settings" — Qwen-specific request handling on this
  channel was actively misbehaving around the same date

OpenCode version

N/A — opencode-go was consumed through its OpenAI-compatible endpoint by
third-party chat frontends; no opencode CLI installed on the affected machine.
All occurrences date 2026-09-03/04 (GMT+8).

Steps to reproduce

1. Point an OpenAI-compatible client at the opencode-go endpoint, model
   qwen3.7-plus
2. Run a multi-turn assistant conversation (ordinary chat/coding traffic)
3. Intermittently (6 of roughly a few dozen replies over ~4 hours in our case) a
   response arrives with finish_reason=stop but its opening is missing — the
   stored content starts with an orphaned backtick or, in one case, a JSON dump
   of the conversation history

Not deterministic; it correlates with replies that open with (or start
shortly after) a fenced code block.

Evidence

Preserved from local session DB (timestamps GMT+8, content trimmed; message
bodies are ordinary Chinese-language coding-assistant conversation, no secrets):

Sample A — 2026-09-03 21:29:47 GMT+8, finish_reason=stop, 464 chars:

reasoning: "..."

content (starts mid-sentence at the surviving backtick):
` 思考块（但内容不会渲染出来）

---

## 总结

**Hermes Workspace 目前没有中文界面**，只有英语（日语在 PR 中）。

| 方案 | 中文界面 | 人格继承 | 配置能力 |
|------|---------|---------|---------|
| 当前 hermes-webui | ❌ 纯英文 | ❌ 需手动切 | 有限 |
...

Sample B — 2026-09-03 21:37:53 GMT+8, finish_reason=stop, 48 chars:

reasoning: "|\\n\\n"

content:
` 加一个类似的 `hw-ctl.sh`，这样管理风格跟现有 webui 完全一致。

要装吗？

Sample C — 2026-09-04 00:52:01 GMT+8, finish_reason=stop, 7437 chars:

reasoning: "...\\n"

content: begins with an orphaned backtick and continues as a raw JSON dump
of prior conversation turns (including `\"tool_calls\": [{...}]` records)
instead of a reply.

Happy to attach the full raw JSON of any sample on request.

Operating System

Fedora 43 (client side); issue is server/opencode-go side — clients are two
independent OpenAI-compatible frontends and both were affected.

Terminal

N/A (both clients are chat frontends, not TUI)

Start at the opencode-go OpenAI-compatible endpoint and trace the Qwen reasoning-stream or think-block stripping path described in the report. Reproduce with qwen3.7-plus using a multi-turn conversation, preserving raw response data and reasoning/content fields. Done means the opening content is retained, reasoning has no debris, and normal responses still finish with finish_reason=stop.