Repository navigation
tui: messages_copy with nothing selected writes an empty clipboard (wipes the previous content) #55924
Closed as not planned
Description
What happens
In the TUI, <leader>y (messages_copy) with nothing selected writes an empty string to the system clipboard. It does not leave the clipboard as it was: whatever was there before is gone.
Steps to reproduce
- Copy some text in another app, so the clipboard has content.
- In the opencode TUI, with the composer focused and no selection active, press
ctrl+xtheny. - Paste anywhere: the clipboard is empty (same on both sides of the clipboard bridge I checked).
Reproduced twice on v2.0.30. The key presses were injected with herdr pane send-keys, so nothing else touched the terminal, and the clipboard was read back before and after.
Expected
Either copy the focused or the last message, or do nothing and leave the clipboard untouched.
Environment
- opencode v2.0.30 (TUI), Linux (Ubuntu 26.04), x86_64
- Plain terminal over SSH inside
herdr0.9.3, which reportsTERM_PROGRAM=herdrand has mouse capture on, so the TUI may never see a selection - X11 present on the host (
DISPLAYset) andxclipinstalled and on PATH terminal.copyleft at its default
Notes
- The troubleshooting page asks for
xclip/xsel(orwl-clipboard) on the machine running opencode. Herexclipis installed and on PATH and the copy is still empty, so this is not a missing-tool problem. - Copying with a mouse selection inside the multiplexer does work (the multiplexer does that copy itself), so the bug is specific to the TUI's own copy action.
- Related, but not the same: tui: "Copied to clipboard" does not update local clipboard over SSH and tmux #50208 ("Copied to clipboard" does not update the local clipboard over SSH and tmux) — there the clipboard is left alone; here it is overwritten with nothing.
Activity
opencode-agent commentedon Oct 16, 2026
Thanks for the detailed report! I tried to reproduce this on v2.0.30 on Linux with an X11 display (
DISPLAYset) andxclipinstalled, leavingterminal.copyat its default. I put a marker string on the clipboard withxclipbefore pressingctrl+xtheny, and read it back afterwards:ywas just typed into the composer. The clipboard was unchanged.xclipafterwards still gave the earlier marker. It was neither emptied nor replaced with the message.So I couldn't get an empty clipboard here. One thing to know:
<leader>ydoesn't use the current selection at all. It copies the text of the last assistant message in the current session. If there's no assistant message, or it has no text, it shows an error toast and doesn't write anything.I didn't test over SSH or inside
herdr. Those are the most likely difference, since opencode also sends the copy to the terminal (the OSC 52 escape sequence), and the multiplexer or SSH clipboard bridge decides what to do with it. These details would help:ctrl+xtheny, and which toast appeared, if any?herdr, or withherdrbut not over SSH?xclip -o -selection clipboardon the remote host, or pasting on your local machine)?Related: #50208 ("Copied to clipboard" does not update the local clipboard over SSH and tmux). That one leaves the clipboard unchanged; yours wipes it.
opencode-agent commentedon Oct 19, 2026
I'm closing this issue for now because we couldn't reproduce it and haven't heard back. On v2.0.30 with X11 and
xclip,<leader>ynever emptied the clipboard. Outside a session it doesn't copy anything. In a session it copies the last assistant message, and our existing clipboard content wasn't wiped. We didn't test over SSH or insideherdr, so the remaining questions were which screen and toast you saw, whether it still happens without SSH or withoutherdr, and how you read the clipboard back.If you still see the clipboard being wiped, please comment here with those details or open a new issue and we'll look again. For the related case where copying over SSH or a multiplexer doesn't reach your local clipboard, see #50208. Thanks for the careful report!