TUI: per-message revert does not dequeue a queued message; it stays in queue and is also copied to the prompt input

[L0GYKAL]

Summary

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

1. Start an opencode session in the TUI.
2. Send message A — the model begins responding.
3. While the response is streaming, type and send message B — it goes into the queue (visible queue indicator).
4. 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.

Environment

• opencode 1.14.50
• TUI client
• Linux (Fedora 44)

Related (not duplicates)

• How do you dequeue a message? #20090 — "How do you dequeue a message?" (question, suggests this gap is user-visible)
• QUEUED tag stuck on all user messages when an assistant message has null time.completed #16856 — QUEUED tag stuck (different cause, UI tag staleness)
• Bug: UI stuck in loading state after undoing and resending message #26654 — UI stuck loading after undo/resend (different code path)
• Reverting doesn't work even though its so simple to implement #27423, Revert is not working. #28634 — closed generic "revert is broken" reports

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: Add ability to unqueue messages #4821: Requests the ability to unqueue a queued message — same core need as described here
• [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.