[BUG] /share clipboard copy fails over SSH #9374

Activity

1. mmabrouk

   added

   bugSomething isn't workingSomething isn't working

   on Jan 19, 2026
2. github-actions

   assigned

   rekram1-node

   on Jan 19, 2026
3. github-actions

   added

   opentuiThis relates to changes in v1.0, now that opencode uses opentuiThis relates to changes in v1.0, now that opencode uses opentui

   on Jan 19, 2026
4. github-actions commented on Jan 19, 2026

   

   github-actionsBot

   on Jan 19, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Copy to clipboard broken over SSH (MobaXterm & Windows Terminal) #6111: Copy to clipboard broken over SSH (MobaXterm & Windows Terminal)
   • clipboard copy not works in remote SSH console. #2773: clipboard copy not works in remote SSH console
   • copying to clipboard doesn't work in a remote session (like a devcontainer) #8237: copying to clipboard doesn't work in a remote session (like a devcontainer)
   • Clipboard copy broken on macOS + WezTerm: appends instead of replacing, plays error sound #8174: Clipboard copy broken on macOS + WezTerm: appends instead of replacing, plays error sound
   • Wayland clipboard copy doesn't populate primary clipboard selection #6110: Wayland clipboard copy doesn't populate primary clipboard selection

   Feel free to ignore if none of these address your specific case.
5. mmabrouk commented on Jan 19, 2026

   

   mmabrouk

   on Jan 19, 2026

   Last edited by mmabrouk

   Author

   More actions

   I am adding here a bit of research about the issue discovered with the agent:

   Root Cause Analysis:

   After investigating the source code (packages/opencode/src/cli/cmd/tui/util/clipboard.ts), I found that:

   1. OpenCode correctly implements OSC 52 in the writeOsc52() function (lines 13-21)
   2. The function writes the escape sequence via process.stdout.write(sequence)
   3. However, when the TUI is running, process.stdout appears to be intercepted by the opentui rendering framework
   4. The OSC 52 escape sequence gets captured by the TUI layer instead of being passed through to the terminal emulator
   5. The native fallback (xclip) also fails over SSH because there's no X11 display ($DISPLAY is empty) [this assumes my setup, opencode over simple ssh]

   Proof that OSC 52 works in my terminal:

   Running this directly in Ghostty successfully copies to clipboard:
   printf '\e]52;c;%s\a' "$(echo -n 'test' | base64)"

   Suggested fix:

   What claude suggest for a fix it to write directly to /dev/tty instead of process.stdout. I don't have much expertise in these systems, so I cannot judge, however it feels there might be lots of edge cases to consider.

   Yes, there's a simple fix. Looking at the code:
   function writeOsc52(text: string): void {
   if (!process.stdout.isTTY) return
   const base64 = Buffer.from(text).toString("base64")
   const osc52 = \x1b]52;c;${base64}\x07
   const passthrough = process.env["TMUX"] || process.env["STY"]
   const sequence = passthrough ? \x1bPtmux;\x1b${osc52}\x1b\\ : osc52
   process.stdout.write(sequence) // <-- This gets intercepted by TUI
   }

   The fix: Write directly to /dev/tty instead of process.stdout:

   import { openSync, writeSync, closeSync } from "fs"
   function writeOsc52(text: string): void {
   if (!process.stdout.isTTY) return
   const base64 = Buffer.from(text).toString("base64")
   const osc52 = \x1b]52;c;${base64}\x07
   const passthrough = process.env["TMUX"] || process.env["STY"]
   const sequence = passthrough ? \x1bPtmux;\x1b${osc52}\x1b\\ : osc52

   try {
   const fd = openSync("/dev/tty", "w")
   writeSync(fd, sequence)
   closeSync(fd)
   } catch {
   // Fallback to stdout if /dev/tty isn't available
   process.stdout.write(sequence)
   }
   }

   Why this works: /dev/tty is a direct handle to the controlling terminal, bypassing any stdout redirection or interception by the TUI framework.

   👍React with 👍3Reacted by Pawel Cioch, Du, Changbin and Adam Spiers
6. aspiers commented on Mar 2, 2026

   

   aspiers

   on Mar 2, 2026

   Contributor

   More actions

   Looks like #12129 fixes this.
7. mmabrouk commented on Mar 2, 2026

   

   mmabrouk

   on Mar 2, 2026

   Author

   More actions

   Yes this indeed was fixed. Closing.
8. mmabrouk

   closed this as completedon Mar 2, 2026