Skip to content

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

Closed

Description

@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)

Activity

  1. github-actions commented on May 22, 2026

    @github-actions
    Contributor

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

    If these cover the same root cause or desired behavior, consider consolidating.

  2. opencode-agent commented on Jul 10, 2026

    @opencode-agent
    Contributor

    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

  3. roryeckel commented on Sep 1, 2026

    @roryeckel

    Seeing the same still, which is quite surprising, this is a high-traffic feature

  4. neriousy commented on Oct 1, 2026

    @neriousy
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions