Activity

1. acaliebe commented on Sep 20, 2026

   

   acaliebe

   on Sep 20, 2026

   More actions

   Workaround that works over SSH + tmux:
   Don't rely on TUI copy-on-selection — it can only write to the remote side and can't reach the local desktop clipboard through SSH/tmux. Instead, register a custom clipboard tool that copies content directly into the client's clipboard, plus a small skill/instruction that triggers on natural language ("copy to clipboard", "ins Clipboard") and calls clipboard({ content: "<exact text>" }).

   The content then travels through the opencode client (which has access to the local clipboard) instead of the remote TUI process — bypassing the broken selection path entirely. Works fine from Fedora/Konsole → SSH → Debian → tmux.

   👎React with 👎1Reacted by khs-kks
2. fQwQf commented on Oct 12, 2026

   

   fQwQf

   on Oct 12, 2026

   More actions

   Still reproducible on 2.0.27 with tmux 3.5a.

   This gets in the way of a pretty normal workflow: leave OpenCode working in tmux on a server, disconnect SSH, then reconnect and attach to the same session later. Copying says it succeeded, but the clipboard on the computer you're connecting from hasn't changed.

   We also reproduced it by starting OpenCode in tmux on a Linux desktop, then attaching to that session over SSH from another computer. Clicking the working directory and choosing Copy path shows “Path copied to clipboard”, but pasting on the SSH client still gives the previous clipboard contents. The copy does reach the original computer's clipboard.

   No clipboard-related tmux settings were changed. The defaults were set-clipboard external and allow-passthrough off. No external OpenCode plugins were loaded.

   In a separate test with the V2 clipboard code and OpenTUI 0.5.17, the OSC 52 payload never reached the outer terminal with those tmux settings, yet the result was attempted and the copy handler reported success. That seems worth distinguishing from an actual clipboard write.
3. fQwQf commented on Oct 12, 2026

   

   fQwQf

   on Oct 12, 2026

   More actions

   A follow-up: the terminal on the SSH client matters too. The second computer in our repro was using Ubuntu's default terminal.

   I checked the actual desktop clipboard this time, rather than just checking whether the escape sequence reached the client:

   • GNOME Terminal 3.56.2 / VTE 0.80.1: the clipboard stays unchanged, even when sending OSC 52 directly without SSH or tmux.
   • kitty 0.41.1: the clipboard updates both directly and through tmux 3.5a with its default settings.

   One confusing detail is that tmux advertises clipboard for both terminals, and load-buffer -w exits successfully in both cases. That isn't enough to confirm the terminal updated the clipboard.

   So fixing the tmux forwarding helps with a terminal that accepts OSC 52, but won't make the GNOME Terminal case work. OpenCode should also distinguish “sent a copy request to the terminal” from a confirmed clipboard write instead of showing the same success message for both.
4. kollyboi commented on Oct 14, 2026

   

   kollyboi

   on Oct 14, 2026

   More actions

   Same issue on opencode 2.0.29 (tmux 3.4, SSH, set-clipboard on, allow-passthrough off).

   Setting the following in ~/.config/opencode/cli.json works for me:

   {
   "mouse": false
   }

   This prevents opencode from capturing mouse events, allowing tmux's native selection and copy functionality to take over. Clipboard copying then works correctly.

   The downside is that all mouse interaction inside opencode is disabled.
5. SpiritInAShell commented on Oct 17, 2026

   

   SpiritInAShell

   on Oct 17, 2026

   Last edited by SpiritInAShell

   More actions

   TL;DR:

   > cat ~/.config/byobu/.tmux.conf
   set -g set-clipboard on
   set -g mouse on
   set -g allow-passthrough on # THIS LINE added to solve for me
   

   my access path: bare metal running Fedora Silverblue -> Gnome -> ghostty -> fish -> ssh remote -t byobu -> fish -> opencode where byobu is sort of a wrapper to tmux !

   While the text below is written by Space Bunny Alpha within OpenCode, I as a person will receice github notification mails. I will try to answer your questions, as soon as possible.

   Agent's analysis:

   Still reproducible on 2.0.32. I traced this to the point where the write leaves OpenCode, and I think we can close the "shared root cause has not been established" question from the issue body.

   Root cause confirmed at the byte level

   OpenCode does not emit raw OSC 52 in a tmux pane. It emits OSC 52 wrapped in tmux DCS passthrough. I captured the pane's actual output with tmux pipe-pane -t %1 'cat >> /tmp/oc-pane.bin' while selecting repeatedly. All 10 observed writes were well-formed passthrough:

   \x1bPtmux;              DCS tmux passthrough opener
   \x1b\x1b]52;c;<base64>  OSC 52, inner ESC doubled as passthrough requires
   \x1b\x1b\               inner ST, ESC doubled
   \x1b\\                  passthrough close
   

   With allow-passthrough off (the tmux default), tmux discards every one of these. The writes are correct; tmux drops them at the passthrough layer. set-clipboard is irrelevant to this path — it governs raw OSC 52, not passthrough. This matches the code quoted in #25253, including the absence of a raw-OSC-52 fallback.

   A test that isolates the variable

   Two checks in the same pane, on the same terminal, with the same tmux config:

   # A: raw OSC 52 through the pane -> reaches the local desktop clipboard
   printf '\033]52;c;%s\a' "$(printf 'test-A' | base64 -w0)"
   
   # B: what OpenCode actually sends (passthrough-wrapped) -> discarded

   A works and OpenCode's copy does not. That rules out the terminal, the SSH layer, and set-clipboard, and leaves passthrough as the only remaining variable.

   One thing that makes this very hard to spot

   fish_clipboard_copy works in a sibling pane, which strongly suggests tmux forwarding is healthy. It isn't. fish writes raw OSC 52 straight to the client TTY and never involves tmux:

   set -l tmux_tty (tmux display-message -p '#{client_tty}')
   test -w $tmux_tty; and printf '\e]52;c;%s\a' "$encoded" >$tmux_tty

   So the working neighbour and the broken TUI are not comparable, and the obvious "tmux forwards OSC 52 fine" conclusion is wrong.

   Fix

   set -g allow-passthrough on

   One line, no OpenCode change, no restart. Mouse interaction inside the TUI keeps working, which is the main drawback of the "mouse": false workaround in the comment above.

   Caveat for Ghostty users: allow-passthrough on crashes Ghostty — slowdown, cursor thrashing between text and pointer, then a crash. Reported in ghostty-org/ghostty#12551 (still open) and mentioned in #25253. I'm on Ghostty and have not hit it on 1.3.1, but it is a real risk, and it is the reason passthrough tends to be off in the first place.

   On the success toast

   The toast is not evidence that anything was copied. In the 2.0.32 bundle, write() resolves successfully once the terminal writer reports attempted, and attempted only means the bytes were written to the pane — not that tmux, let alone the local desktop, acted on them. Passthrough is fire-and-forget, so OpenCode cannot observe the drop, and there is no error path to surface.

   Scope

   This addresses the passthrough layer only. It does not address the GNOME Terminal / VTE case in the comment above, where OSC 52 does not update the clipboard even sent directly with no tmux involved — that looks like a separate terminal-capability issue.

   Environment: OpenCode 2.0.32, tmux 3.4 / byobu 6.11, fish 4.9.3, outer terminal Ghostty (xterm-ghostty as reported by the tmux client), remote host Linux Mint 22.3, set-clipboard on, allow-passthrough was off, no DISPLAY/WAYLAND_DISPLAY remotely, no plugins.

   👍React with 👍2Reacted by Christoph Raab and Christoph Raab
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report and diagnostics. I tried to reproduce this on 2.0.11 with tmux 3.5a (set-clipboard external, allow-passthrough off, no DISPLAY or WAYLAND_DISPLAY). I used a simulated outer terminal that records everything sent to it. My simulated mouse drags never started a selection in the TUI, though, so I couldn't watch what tmux does with the clipboard write. A maintainer with a real terminal (Konsole or similar) over SSH and tmux will need to check this.

   From reading the code, the TUI counts an OSC 52 clipboard write as successful once it has sent the escape sequence, whether or not anything received it. That would explain why "Copied to clipboard" shows up even when your local clipboard doesn't change. This part is tracked in #59664.

   Things worth trying on your side (none of them tested here):

   • In tmux's documentation, set-clipboard external ignores clipboard sequences sent by programs running inside tmux. Try set -s set-clipboard on.
   • If that alone doesn't help, also try set -s allow-passthrough on. This is the workaround reported in tui: clipboard copy silently fails inside tmux (OpenTUI wraps OSC 52 in DCS passthrough that tmux drops) #59134.

   It would help a lot to know whether either setting makes copying work for you.

   Related issues:

   • tui: clipboard copy silently fails inside tmux (OpenTUI wraps OSC 52 in DCS passthrough that tmux drops) #59134: the same tmux copy problem on 2.1.4, closed as a duplicate of this issue, with notes on the tmux passthrough
   • TUI: "Copied to clipboard" toast shown even when nothing was copied (OSC52 "attempted" treated as success) #59664: "Copied to clipboard" shown even when the copy never arrives (open)
7. ky-ko commented on Oct 28, 2026

   

   ky-ko

   on Oct 28, 2026

   More actions

   Thanks for following up. On my setup, set-clipboard on is already enabled, so that does not resolve the issue.

   Enabling allow-passthrough on caused other keyboard shortcut issues in my setup, including an SSH disconnect when pressing Ctrl+V. I haven’t isolated the cause, so I’m keeping passthrough disabled rather than treating it as a viable workaround.

   The working workaround here has been "mouse": false in OpenCode’s cli.json, allowing tmux to handle selection and copying. Copying through tmux load-buffer -w - also reaches my local clipboard.

   Could OpenTUI support sending plain OSC 52 inside tmux, allowing tmux’s native set-clipboard on handling to forward it, instead of requiring DCS passthrough? This was explicitly suggested in #59134 before it was closed as a duplicate of this issue.

   That would address the clipboard delivery problem without requiring allow-passthrough on or disabling mouse interaction in OpenCode. The misleading success notification tracked in #59664 is related, but fixing that alone would not restore clipboard delivery.
8. Blandinium commented on Nov 12, 2026

   

   Blandinium

   on Nov 12, 2026

   More actions

   I opened #63578 to fix this. Inside tmux, the TUI now hands the copied text to tmux load-buffer -w -t <client>, aimed at the client showing the OpenCode pane. tmux then forwards it to that client's terminal, so it works with the default set-clipboard external and allow-passthrough off.

   Tested with Kwi (libghostty) → SSH → tmux. If you can, please try the branch with your terminal and report back on the PR.