[FEATURE]: Reply to a chat selection with a quote in the Desktop app #56836

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Summary

Let me select a snippet of a message in the Desktop chat transcript, attach a comment to it, and send the pair — the way Claude Code and ChatGPT do it. Selecting text should surface a small inline affordance ("Reply"); choosing it opens a compact composer showing the snippet as the quoted context, and what I send arrives in the session as a quote block plus my comment.

Why this matters

Quoting a specific sentence is the main way to give precise feedback on a long answer. Right now that costs six steps: drag-select, copy, click the composer, paste, hand-wrap it in > markers, then type the comment. The quote is also easy to lose — pasted text is indistinguishable from something I typed myself, so the model has no structural signal about which part of its previous turn I am reacting to.

What already exists (so this is a small delta)

This asks for a new interaction, not new rendering:

• Selection inside the Desktop transcript already works. [FEATURE]: Copy selection as markdown in Desktop app #54002 is about the copy semantics of such a selection (rendered text vs markdown source), which only makes sense because selections exist.
• [FEATURE]: Pin messages and selected text in the Desktop chat #55195 asks to pin messages or a selected range. That is about retrieval — jumping back to it later.
• Neither covers replying to a selection, which is the interaction requested here.
• The TUI client already exposes prompt insertion (client.tui.appendPrompt({ body: { text } }), used by third-party plugins such as opencode-quick-reply). So the "put text into the composer" half of this already has a proven shape; the missing half is the selection event and the inline affordance.

Proposed behavior

1. While text inside a user or assistant message is selected, show a small affordance anchored near the selection (Claude Code places it just below-right of the selection). It must not appear for selections outside messages.
2. Activating it opens a compact inline composer anchored to the selection. The selected text appears as quoted context above the input, truncated with an ellipsis if long.
3. Sending inserts the following into the session and the transcript:
   • a markdown blockquote of the selected text (trimmed, with markdown structure preserved where the selection aligns to block boundaries — same partial-block question [FEATURE]: Copy selection as markdown in Desktop app #54002 raises), followed by
   • the typed comment as normal message text.
4. Escape or clicking away dismisses without sending. Plain copy must keep working untouched — the affordance is additive, never a replacement for Cmd/Ctrl+C.
5. Selections spanning multiple messages should either be clamped to the message that contains the selection anchor or rejected with the affordance simply not shown. Silently producing a malformed quote would be worse than doing nothing.

Optional, for plugin parity

If the built-in interaction is not wanted, exposing the same surface to plugins would let the ecosystem build variants. The three pieces that are missing today:

• an event fired when a transcript selection settles, carrying sessionID, messageID, partID, and the selected range plus its text, so a plugin can decide what to do without scraping the DOM;
• a slot anchored to that selection (existing slots such as session.composer.top and session.panel are fixed-position, so a plugin cannot currently render something that follows the selection);
• a Desktop-side equivalent of the TUI's prompt insertion, so a plugin can put the quote into the composer.

With those three, this feature and several neighbours (#54002's markdown copy, #55195's pinning) become plugin-implementable without further core work.

Scope

Desktop (and Web, for parity). The TUI is a separate problem — terminal text selection belongs to the emulator, so a TUI equivalent would need its own design and is explicitly out of scope here.

Environment (for context)

• opencode version: 2.0.32
• Install/channel: Desktop app
• App: OpenCode Desktop 2.0.32
• OS: macOS (darwin arm64)