Bug: Web UI multi-turn sessions drop reasoning blocks — 400 "reasoning_text must be passed back" (openai-responses custom provider)

[hiro-nikaitou]

Bug: Web UI multi-turn sessions drop reasoning blocks — multi-turn requests fail with 400 "The reasoning_text in the thinking mode must be passed back to the API"

dsh 0.1.0-rc.6 (npm global), Node 22, Windows. Custom provider configured as openai-responses against an OpenAI-compatible gateway (OpenCode Go, baseURL .../v1). Models are hand-declared (no reasoningEfforts field).

Symptom

• Web UI multi-turn agent sessions (with tool calls): after the first few turns, the next request fails with:
  OpenAI API error (400): invalid_request_error: Error from provider (Console Go): Upstream request failed: [invalid_request_error] The reasoning_text in the thinking mode must be passed back to the API.
• Single-turn / headless runs are fine. dsh --profile headless works, including tool-call turns.

Evidence that the gateway and pi-ai are NOT at fault

1. Gateway streams reasoning correctly: captured the live SSE stream — response.output_item.added (item type reasoning), 35× response.reasoning_text.delta, response.output_item.done, and response.completed usage includes output_tokens_details.reasoning_tokens. Also returns reasoning in non-streaming mode.
2. pi-ai 0.82.1 produces thinking blocks in every scenario: reproduction scripts using the exact pi-ai version shipped with dsh (streamSimple, openai-responses) yield thinking_start → thinking_delta… → thinking_end for: single-turn, multi-turn, with tools, without reasoningEffort, and with reasoning: "max". The model (deepseek-v4-pro) even produces thinking with no effort param and no tools.
3. Same install, same gateway, same settings — headless sessions record reasoning correctly: headless session.jsonl.zstd contains reasoning-chunks storage rows, assistant/message content includes {"type": "reasoning", "text": …} blocks, and source.replayState.blocks includes the reasoning signature.
4. Web UI sessions record zero reasoning: in the failing session, all 30 assistant/message records have content with only text/tool-call blocks, reasoning-chunks rows = 0, and replayState.blocks has no reasoning entry. (Verified in the raw .zstd log, not just the export.)

Mechanism

Because the reasoning block (and its thinkingSignature) never reaches the message layer in Web UI sessions, the multi-turn conversion (replayedAssistant / pi-ai convertResponsesMessages) has nothing to pass back — reasoning_text is absent from the next request, and the gateway rejects it.

Direct reproduction of the mechanism with pi-ai: multi-turn request without the previous reasoning item passed back → request fails; with the reasoning item → succeeds.

Suggested focus

Web UI session path vs headless path diverge somewhere between the adapter stream and the persisted assistant/message — headless persists reasoning blocks, Web UI does not, on the same build.

Related: #199 (adapter drops thinking for vLLM delta.reasoning format — same family, different wire shape).