fix: blank assistant text - finish-reason regression after AI SDK v6 migration

[kkugot]

Issue for this PR

Closes #20465

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fixes blank assistant text in TUI when MCP servers are enabled, a regression introduced in v1.3.4 by the AI SDK 5 -> 6 upgrade.

Root cause: The v6 finish-reason adapter changed the default unmapped reason from unknown to other. The prompt loop continue sets in prompt.ts had unknown removed but other was never added as a replacement. This causes the loop to exit after MCP tool calls before the model produces final text. MCP amplifies this because tool-enabled requests hit this code path far more often.

Additional fix: The TUI AssistantMessage component rendered empty space for intermediate assistant messages whose parts were all hidden (completed tools with details off, empty text). Added a reactive visible memo that hides the entire message when no parts would render.

How did you verify your code works?

• Tested locally with MCP enabled: assistant text renders correctly, symptom gone
• Tested with MCP disabled: no behavior change
• bun typecheck — no new errors (only pre-existing ripgrep.ts errors on dev)

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Related PRs Found:

1. PR fix(opencode): run transformParams middleware unconditionally for all call types #19558 - "fix(opencode): run transformParams middleware unconditionally for all call types"

   • fix(opencode): run transformParams middleware unconditionally for all call types #19558
   • Why related: This PR addresses middleware execution issues with request transformation, similar to the LLM middleware fix in the current PR that handles v6 request param shapes (messages, input, prompt).

2. PR fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers #14973 - "fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers"

   • fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers #14973
   • Why related: This PR addresses the prompt loop exit issue after tool calls, which relates to the finish-reason mapping changes in the current PR.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[kkugot]

I am keeping this branch up-to date with dev, would be thankful if this can be merged. engineers using Oracle Code Assist could not use opencode with Open AI models with responses API because of this bug. This is since version 1.3.4

[rekram1-node]

@kkugot let me look over this

[rekram1-node]

The LLM middleware in llm.ts targeted args.params.prompt for applying ProviderTransform.message(), but v6 Responses requests use messages or input. This meant message normalization was silently skipped on Responses requests.

Im not sure this is accurate

[kkugot]

Addressed both review comments:

1. Removed the llm.ts transformParams change entirely. @rekram1-node you were right — the middleware always receives LanguageModelV3CallOptions which only has prompt. The messages/input keys only exist inside model implementations after getArgs() converts, but transformParams runs before that. The first commit now only touches prompt.ts.

2. Updated PR description — removed the inaccurate claim about v6 Responses using different param keys.

The PR now has two commits:

• prompt.ts: adds "other" to the two finish-reason continue sets (the actual bug fix)
• index.tsx: hides empty intermediate assistant messages in the TUI (prevents blank space from rendered-but-empty message nodes)

[rekram1-node]

Why does your provider not send valid stop reasons, we cant just continue on all others i dont think, there are many cases that can trigger this afaik

[kkugot]

Why does your provider not send valid stop reasons, we cant just continue on all others i dont think, there are many cases that can trigger this afaik

It does, we use OpenAI (@ai-sdk/openai) via responses API through enterprise layer and it works well in Codex and other harnesses. But your question is valid and I am taking it to discuss if there is any modification to stop reasons.

[kkugot]

The AI SDK 6 upgrade dropped support of "unknown" but has not added support of "other" in full (which is valid reason in V6)

[rekram1-node]

this pr has so many unrelated changes, i thought it'd be a 2 line pr?

[kkugot]

@rekram1-node the rebase went wrong, fixing

[kkugot]

this pr has so many unrelated changes, i thought it'd be a 2 line pr?

Ready for your review