Local copy writes the clipboard natively and via OSC 52 at once, racing the terminal (macOS) #59052

Activity

1. opencode-agent commented on Oct 25, 2026

   

   opencode-agentBot

   on Oct 25, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I couldn't reproduce this here: the warning comes from Alacritty writing to the macOS pasteboard, and this sandbox only runs Linux, so it needs a maintainer on macOS with Alacritty to confirm.

   The code does match what you describe. In 2.1.4 and on the current dev branch, TUI copies use destination: "all-available". In @opentui/core that starts the native clipboard write and sends OSC 52 straight away without waiting for the native write, so locally OpenCode and Alacritty both write the pasteboard at the same moment. The "best-available" mode you mention writes to the native clipboard first and sends OSC 52 only over a remote connection or when the native write fails.

   Related: #50208 (copying over SSH and tmux doesn't reach the local clipboard), which any change here needs to keep working.
2. Dante-dan commented on Oct 25, 2026

   

   Dante-dan

   on Oct 25, 2026

   Last edited by Dante-dan

   Contributor

   More actions

   I prepared a focused fix using best-available: local copies wait for the native write, with OSC 52 retained for failed/unsupported host writes and remote sessions.

   Patch. The existing clipboard test now covers these routes: 7 tests passed across 10 reruns, and bun run check passed. The macOS/Alacritty warning itself remains unconfirmed locally; this does not resolve the separate tmux forwarding/capability limitations in #50208.

   Full TUI suite result: with isolated XDG paths, 1,552 passed, 2 skipped, 5 failed (watcher notification, two update lifecycle checks, plugin activation reload, and shared tab closing). The first run using default user data paths had 62 failures and 1 error, including sandbox permission errors. These full-suite failures are separate from the passing clipboard tests; I have not established that they also fail on the base revision.
3. w3irdrobot commented on Oct 28, 2026

   

   w3irdrobot

   on Oct 28, 2026

   More actions

   Seeing related behavior on Linux:

   • OS: Fedora Linux 44 KDE Plasma Desktop Edition, Wayland
   • Terminal: Ghostty 1.3.1-4.fc44
   • OpenCode: 2.1.4

   Copying from OpenCode produces correct text when pasted into GUI apps, but pasting into Ghostty intermittently fails with both Ctrl+Shift+V and right-click → Paste. Sometimes Ctrl+Shift+V produces literal 8;6u instead.

   Findings:

   • Clipboard offers text/plain and text/plain;charset=utf-8.
   • Re-publishing it with wl-paste --no-newline | wl-copy --type text/plain restores reliable pasting.
   • A standalone OSC 52 write using printf pastes correctly.
   • Running ghostty --clipboard-write=deny -e opencode makes copying from OpenCode and pasting into another terminal reliable across repeated attempts.

   This supports the concurrent native/OSC 52 write race described here, though we haven’t tested a patched build.

   🚀React with 🚀1Reacted by dotknewt
4. Novaenn commented on Nov 4, 2026

   

   Novaenn

   on Nov 4, 2026

   Last edited by Novaenn

   More actions

   Also reproducible on Linux/X11 with Alacritty on Ubuntu 24.04 LTS, so this is not macOS-specific.

   Environment

   • opencode 2.2.5 (release binary)
   • Alacritty 0.13.2, X11 session (XDG_SESSION_TYPE=x11, GNOME/Xorg)
   • No tmux and no third-party clipboard manager (no xfce4-clipman, klipper, CopyQ, xsel)

   Symptom

   After roughly 4-5 copies in the TUI, Alacritty logs:

   [5.953259209s] [WARN ] [alacritty] Unable to store text in clipboard: Failed to set new owner of XCB selection
   

   /tmp/Alacritty-<pid>.log contains only that single line. The clipboard content itself is correct (xclip -o -selection clipboard returns the copied text), so this is a spurious warning rather than lost data.

   Cause (consistent with the analysis above)

   clipboard.write() in the 2.2.5 bundle still calls writeText(..., { destination: "all-available", selection: "clipboard" }), which starts both:

   1. the in-process native write. On X11, opentui's clipboard backend opens its own XCB connection and calls xcb_set_selection_owner for CLIPBOARD;
   2. an OSC 52 sequence to Alacritty.

   Alacritty's x11-clipboard crate sets itself as selection owner and then immediately verifies with GetSelectionOwner. When opencode's xcb_set_selection_owner lands in between, the verification returns Error::Owner, which is exactly the "Failed to set new owner of XCB selection" message. It is timing-dependent, hence only every few copies.