Repository navigation
[Bug]: Stray message number like @12@ shows up at the end of replies on OpenCode V2 #642
Description
Bug Description
Since switching to OpenCode V2, some of the model's replies end with a stray message number on its own line, for example @12@.
DCP numbers each message in the conversation and tells the model not to write those numbers. Sometimes the model writes one anyway, usually a guess at the next number. In V1 this was quietly cleaned up before the reply was saved. In V2 it isn't, so the number is saved with the reply and shows up in any app that displays the chat.
How often: in my history, 56 of about 23,500 replies have it. All of them are from after I moved to V2. In 53 of the 56 it is the very last thing in the reply. Seen with Claude Opus 5.5, Claude Sonnet 5.5, and GLM 5.3 Flash.
Expected Behavior
The stray number is removed from the reply, as it was in V1, so it never appears in the saved chat or on screen.
How to see it
- Use DCP 3.2.0 on OpenCode V2 with the default settings.
- Have a longer conversation where the model reads files or runs commands between replies.
- Look at the end of the model's replies. Now and then one ends with a blank line and a tag like
@12@. - To check the saved text directly, look at the reply in OpenCode's own database. The last characters are a line break, then
@12@.
It doesn't happen on every reply, so it can't be triggered on demand.
My guess (not confirmed)
DCP's V1 code had a step that cleaned up the model's reply after it was written. The V2 setup only seems to clean up what is sent to the model, not what comes back. I haven't checked whether V2 offers a place to hook into replies.
Debug Context Logs
I don't have a DCP debug log for this. The saved reply text in OpenCode's database is the evidence. I can capture a log if you want one.
DCP Version
3.2.0
Opencode Version
2.0.18
Model
Other: Claude Opus 5.5, Claude Sonnet 5.5, GLM 5.3 Flash
Additional Context
- The message numbers are the short
@N@style (the default). - Workaround: my own app now removes a tag at the very end of a reply. Tags that appear mid-sentence are left alone, since people may quote them.
- Definition of done: a reply that would have ended in a tag is saved and shown without it.
- I did not find an existing issue about this.
Activity
fix(text): strip echoed DCP message-id tag from the end of replies
clappingmonkey commentedon Oct 16, 2026
Same here. A stray message ID on its own line shows up at the end of the reply.
Setup
compactIDs, auto compress mode (nudgeForce: "soft")@ai-sdk/anthropic), so it isn't specific to OpenAI or GPT ([Bug]: GPT models copy compact @N@ reference tags into their replies on OpenCode v2 #632)What I see: in a long session (migration work with lots of tool calls), a reply occasionally ends with a blank line and an
@N@tag. I have to point it out to the agent, because the tag is stripped from its own context.Notes from reading the 3.2.0 code
setup()only cleans the context sent to the model (stripHallucinationsincontext/compaction). Nothing touches the stored reply, so the tag stays in the session.experimental.text.completepath (passingidFormat) but doesn't change V2. V2 will still need a stream-level fix, such ashttp.response/experimental.ws.receive, or a reply-rewrite hook in OpenCode.The impact for me is cosmetic. Compression, context and caching all keep working.
faileon commentedon Oct 23, 2026
Same issue on latest, auto compression rarely works, session is polluted with messages in assistant blocks:
fix(ui): keep DCP decorations out of authored message text