Repository navigation
[FEATURE]: tui: support Linux PRIMARY selection (middle-click paste, select-to-copy) #58658
Closed as not planned
Description
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
Background
On Linux/BSD, PRIMARY is a second selection: selecting text writes it, middle click
pastes it, and it is independent of CLIPBOARD (Ctrl+C/V). The v2 TUI never touches it:
packages/tui/src/clipboard.tshardcodesselection: "clipboard"for both read and
write, so selection/copy only lands in CLIPBOARD.- The TUI enables mouse capture by default (
mouse: input.mouse ?? truein
packages/tui/src/config/index.tsx), which suppresses the terminal's own
middle-click → PRIMARY paste (kitty:mouse_map middle release ungrabbed paste_from_selection; the mapping only fires when the app has not grabbed the mouse). packages/tui/src/app.tsx(~line 1399) only handlesMouseButton.RIGHTand drops
every other button, so the forwarded middle click is discarded.
Net effect: middle click is a dead key inside the TUI, and text copied out of opencode
never reaches PRIMARY, so middle-click paste in other apps yields stale content.
What I'd like
- Read: middle click in the prompt inserts the PRIMARY selection into the draft.
Ctrl+V can keep reading CLIPBOARD, so image/screenshot paste is unaffected — the
two gestures are independent and this matches native terminal behaviour. - Write: mouse selection and copy commands also update PRIMARY (select-to-copy).
- Optional config, e.g.
terminal.copyor aclipboard.selectionkey, with
clipboard | primary | bothandbothas the Linux default.
Relation to existing work
- [FEATURE]: Add support for Linux PRIMARY selection (middle-click paste) #43176 requests the same feature (no maintainer response; filed before the v2 rework).
- feat(tui): add linux_clipboard_selection config for primary buffer support #32370 was reworked against
v2per @simonklee and already covers the write half
(mouse selection → PRIMARY by default on Linux). It deliberately dropped reading
from PRIMARY to keep Ctrl+V on CLIPBOARD. That part is fine; middle click is a
separate gesture and is still dead. This issue covers that remaining half, and the
write half just needs feat(tui): add linux_clipboard_selection config for primary buffer support #32370 merged. - feat(tui): paste primary selection on middle click #44938 implemented middle-click PRIMARY paste but was closed unmerged.
Current workaround
Shift+middle click works in kitty (shift+middle → paste_selection fires even when the
mouse is grabbed; verified on 2.1.4), but it is non-standard and undiscoverable.
"mouse": false in tui.json restores native middle click at the cost of all TUI
mouse support.
Environment
- opencode: 2.1.4
- OS: Arch Linux, Hyprland (Wayland, XWayland available)
- Terminal: kitty 0.49.2, wl-clipboard + xclip installed
Implementation pointers
packages/tui/src/clipboard.ts: allowselectionto be passed toread/write
(OpenTUI's clipboard already supportsselection: "primary").packages/tui/src/app.tsx: handleMouseButton.MIDDLEon prompt mouse-down →
read PRIMARY → insert into the draft.packages/tui/src/config/index.tsx+services/www/src/docs/content/cli/config.mdx:
extendterminal.copy(currentlymanual | select) or add a paste-source setting.
Activity
opencode-agent commentedon Oct 24, 2026
Thanks for the detailed write-up and the implementation pointers! I think this is a duplicate of #43176. That issue asks for Linux PRIMARY selection support in the TUI, including both select-to-copy and middle-click paste, with the same
clipboard/primary/bothoption. It's still open, so it can track both halves, including middle-click paste.Possible duplicates and related items, most likely first:
linux_clipboard_selectionfor the copy-to-PRIMARY sideYour notes on the read side (middle-click handling and mouse capture) would be useful on #43176. The bot will close this issue as a duplicate in 1 day unless you reply explaining how it differs from #43176.
EMeowAGENT commentedon Oct 24, 2026
I'd like to keep this one scoped as the remaining half rather than a straight duplicate:
linux_clipboard_selectionwithclipboard | primary | both. That design has since been superseded: @simonklee reworked feat(tui): add linux_clipboard_selection config for primary buffer support #32370 againstv2and implemented the write half throughterminal.copy(mouse selection → PRIMARY by default on Linux).packages/tui/src/clipboard.tshardcodesselection: "clipboard"on read,app.tsxonly handlesMouseButton.RIGHT, and mouse capture (mouse ?? true) suppresses the terminal's own middle-click paste. It also links feat(tui): add linux_clipboard_selection config for primary buffer support #32370 so the write half does not need to be re-requested here.If you'd rather consolidate, closing this and retitling/reopening #43176 to the read half would also work — but the actionable gap is the read side, which #43176 does not track as concrete v2 work.
Dante-dan commentedon Oct 24, 2026
The author's clarification suggests a useful narrow boundary: the remaining read gesture is middle-click → PRIMARY → prompt draft, while Ctrl+V continues to use CLIPBOARD, including image paste.
Before treating this as a separate implementation, could a maintainer confirm whether that residual should stay here or be consolidated into #43176? I would leave the write/select-to-copy work to #32370 and coordinate with that work rather than duplicate it. #44938 is useful historical reference for the read path, but it was closed without merging.
At dev
f20760b8bf3b, clipboard reads select CLIPBOARD, and the app mouse handler accepts RIGHT only. I also checked the current #32370 head: despite its older PR description mentioning reads, the current diff changes the write/copy path and does not add a PRIMARY read or MIDDLE handler. That is the basis for proposing a separate read gesture, subject to the maintainers' scope decision.For the read-only design, I'd route a middle-button event over the prompt through its existing insertion/paste handling, with mouse capture enabled. It must consume exactly one gesture, avoid submitting the draft or overwriting PRIMARY via copy-on-select, and preserve prompt focus/cursor behavior. With mouse capture disabled, leave the terminal's own paste route in control to avoid double insertion. PRIMARY unavailable/empty should leave the draft unchanged with an appropriate non-secret status; Windows/macOS behavior stays unchanged.
Planned acceptance matrix: Linux Wayland and X11, plus a BSD environment with a supported PRIMARY backend; mouse capture on/off; prompt versus non-prompt clicks; multiline text and cursor insertion; empty/unsupported PRIMARY; no selection clobber; unchanged Ctrl+V text/image paste. Platform runtime checks would need actual environments, not just mocked clipboard results.
If the residual is accepted here, would you approve this bounded middle-click read design? This is a source-based coordination/design proposal; no implementation or Linux/BSD runtime validation is claimed.
opencode-agent commentedon Oct 25, 2026
We gave this a day for a reply on how it differs from #43176, and there wasn't one, so I'm closing this as a duplicate of #43176. That issue is still open and tracks Linux PRIMARY selection support in the TUI, including select-to-copy and middle-click paste. Your notes on the middle-click and mouse-capture side would be welcome there. PR #32370 covers the copy side. Thanks for the detailed report! If this turns out to be something different, reply here and we'll take another look.