You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TUI: per-message revert does not dequeue a queued message; it stays in queue and is also copied to the prompt input #28843
In the TUI (opencode 1.14.50), clicking the per-message revert button on a message that is currently in the queue does not actually remove it from the queue. Instead, the message ends up in two places: it stays in the queue and is copied into the prompt input/composer. The next time the queue is drained it gets sent again, even though the user explicitly reverted it.
This is the opposite of the user's intent when pressing revert on a queued message: "remove this from the queue, I don't want it sent."
Repro
Start an opencode session in the TUI.
Send message A — the model begins responding.
While the response is streaming, type and send message B — it goes into the queue (visible queue indicator).
Press the per-message revert button on message B.
Actual
Message B remains in the queue (still scheduled to send when A finishes).
Message B's text is also copied into the prompt/composer input.
When A's turn ends, B is sent anyway.
Expected
Reverting a queued message dequeues it.
It should not also be copied into the composer (that's a separate "edit" affordance, not "revert").
If the user wants to recover the text, "revert" should leave it on a draft history, not silently re-arm it for sending.
Why this matters
This is a silent surprise-send: the user took an explicit action to cancel a message, and opencode sent it anyway. For destructive prompts (e.g. "delete X", "run migration") this is exactly the kind of accidental execution the revert affordance exists to prevent.
[FEATURE]: Better controls/UX for queued messages. #8685: Describes the same symptom (revert on a queued message produces a duplicate rather than removing it) and explicitly requests 'cancel' / 'edit' actions on queued messages
If these cover the same root cause or desired behavior, consider consolidating.
In the OpenCode v2 TUI, undoing a message that is still waiting in the queue cancels it: it's removed from the session inbox and its text goes back into the prompt input. It no longer stays queued as well.
Activity
github-actions commentedon May 22, 2026
This issue might be a duplicate of existing issues. Please check:
If these cover the same root cause or desired behavior, consider consolidating.
opencode-agent commentedon Jul 10, 2026
Latest huddle decision: undo should consume queued/steering messages before normal message undo. A queued message action should read as delete/edit, not jump/revert; editing should bring it back into the composer. Source discussion: https://slack.com/archives/C0BE69AHCQP/p1783640722114279
roryeckel commentedon Sep 1, 2026
Seeing the same still, which is quite surprising, this is a high-traffic feature
neriousy commentedon Oct 1, 2026
In the OpenCode v2 TUI, undoing a message that is still waiting in the queue cancels it: it's removed from the session inbox and its text goes back into the prompt input. It no longer stays queued as well.
Fixed in #47343.
Closing as completed. If a reverted queued message still gets delivered on v2, please open a new issue.