[Bug]: OpenCode provider can duplicate the assistant response / replay a large suffix chunk at completion

[timm-u]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

When using the OpenCode provider in T3 Code, the final assistant response can appear corrupted near completion, often looking like the final response was duplicated or that a large suffix chunk was replayed.

After deeper investigation, this appears to be caused by T3 Code’s OpenCode delta assembly logic rather than the desktop shell itself.

Steps to reproduce

1. Start the desktop app (also reproduced from source on current main).
2. Configure and use the OpenCode provider.
3. Select an OpenCode-backed model (for me this reproduced with Kimi K2.6).
4. Send a prompt that produces a medium-length multi-paragraph response.
5. Watch the assistant response as it streams and especially when it finishes.
6. Repeat a few times if needed; it does not happen on every very short response, but it is frequent enough with ordinary
   longer outputs.

Notes:

• This does not require a special prompt.
• Any response long enough to stream across many chunks seems sufficient.
• I reproduced this in the official desktop app and on current upstream source.

Expected behavior

The assistant response should stream once and finalize once.

The final message should exactly match the intended output with:

• no dropped characters during streaming
• no duplicated suffix chunk
• no large corrective replay at completion

Actual behavior

The assistant response streams mostly normally, but near the end the final message can become corrupted and look like:

• the final response was emitted twice, or
• a previously generated suffix chunk was appended again at completion

There can also be a brief visual flash right as the response settles, but that seems secondary. The main issue is that
the final assistant text itself can be wrong.

Impact

Major degradation / frequent failure.

This makes OpenCode-backed models frustrating to use because the final answer can be visibly corrupted, especially on normal multi-paragraph responses.

Version or commit

upstream/main @ dbebc38
Also reproduced in the official desktop app build.

Environment

• OS: Windows 11
• App: Desktop app
• Provider: OpenCode
• Model: Kimi K2.6
• Bun: 1.3.10 locally
• Also reproduced in the official desktop app build, not only in a local fork

Logs or stack traces

Likely relevant area:

• apps/server/src/provider/Layers/OpenCodeAdapter.ts

After inspecting failing provider logs, the likely problem is:

• raw OpenCode message.part.delta chunks are already valid
• T3 Code tries to dedupe overlap between consecutive delta chunks
• that overlap logic strips legitimate leading characters from normal chunks
• later message.part.updated arrives with the correct full text
• T3 Code then emits a large corrective suffix, which looks like duplicated final output

Examples observed from real logs:

• "Bonus" became "onus"
• " usage" became "usage"
• "different" became "ifferent"
• "and" became "d"

This strongly suggests the problem is in OpenCode delta assembly, especially around:

• appendOpenCodeAssistantTextDelta(...)
• the message.part.delta handling branch

Workaround

I verified a local fix in my fork by changing the OpenCode delta assembly logic to:

• append raw message.part.delta chunks exactly as received
• keep message.part.updated snapshot merging only as a reconciliation step

That local change appears to stop the persistent final-response corruption for me.

So there is a practical code-level workaround in the OpenCode adapter path, but no user-facing workaround in the official
app besides avoiding OpenCode for affected models.

Additional note

This appears provider-specific. I have mainly observed it with OpenCode-backed models and not as a general T3 Code
rendering issue.