bug: local MCP can cause assistant responses to disappear in v1.3.4

[kkugot]

Description

When a local MCP server is enabled in v1.3.4, assistant responses can fail to render in the UI during tool-using turns.

This appears to come from two regressions in the 1.3.4 refactor:

• MessageV2.toModelMessages() changed toModelOutput to expect an object instead of raw output, which can break tool result serialization.
• message.part.delta events are now transient bus events instead of sync-backed events, so streamed text deltas can be missed by late/reconnecting subscribers.

Plugins

None required

OpenCode version

v1.3.4

Steps to reproduce

1. Configure any local MCP server.
2. Start a session on v1.3.4.
3. Ask for a prompt that causes MCP tool usage.
4. Observe that the model completes work but the assistant response may not render or may render incompletely.

Screenshot and/or share link

N/A

Operating System

macOS

Terminal

N/A

Proposed fix

• Make toModelOutput backward-compatible with both raw output and { output, ... } input.
• Make message.part.delta sync-backed again so streamed text survives delayed SSE startup and reconnects.

[kkugot]

Additional investigation narrowed the main regression cause.

Confirmed behavior

This is not just a TUI paint problem.

From an affected run:

• request starts normally
• provider/server work happens
• no assistant text parts are produced
• processor exits cleanly with:
  • blocked=false
  • aborted=false
  • hasError=false
  • hasText=false
  • finish=other
• prompt loop then exits as if the assistant turn completed successfully

I also added a prompt-side guard, which now surfaces:

• Model finished with no output (finish=other)

That confirms the backend is treating an empty terminal provider response as a valid completed assistant turn.

Likely regression cause

The regression appears to come from the AI SDK v6 migration in v1.3.4.

Relevant commit:

• c33d9996f feat: AI SDK v6 support (#18433)

Critical behavior change:
packages/opencode/src/provider/sdk/copilot/responses/map-openai-responses-finish-reason.ts

Before (v1.3.3):

default:
  return hasFunctionCall ? "tool-calls" : "unknown"

After (v1.3.4):

default:
  return hasFunctionCall ? "tool-calls" : "other"

Why this matters

session/prompt.ts treats finished assistant messages as terminal unless the finish reason is tool-calls (historically also unknown was treated specially).

So after v1.3.4:

• a nonstandard raw Responses API finish reason from oca-responses
• gets mapped to other
• prompt loop treats that as a successful terminal assistant response
• but no text/tool output was actually emitted
• result: silent blank assistant turn

This matches the observed logs exactly.

What this means

The main regression is likely not MCP-specific and not primarily caused by TUI rendering.
MCP may still increase the odds of hitting this path, but the core bug is that unknown Responses finish reasons became terminal success in v1.3.4.

Recommended fix

1. Revert the Responses finish-reason default mapping from other back to unknown
2. Keep a prompt-side safeguard so empty finished assistant turns are never treated as valid success
3. Optionally add a targeted retry for known transient raw reasons if we identify the exact raw incomplete_details.reason coming from oca-responses

Current evidence

Affected run showed:

• provider/server activity
• no text/tool output
• finish=other
• clean processor stop
• prompt loop exit

That is the strongest evidence so far for the root cause.

[kkugot]

Looks like this is an incorrect diagnosis, see #20465