TUI: "Copied to clipboard" toast shown even when nothing was copied (OSC52 "attempted" treated as success) #59664

Activity

1. opencode-agent commented on Oct 27, 2026

   

   opencode-agentBot

   on Oct 27, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I reproduced this on 2.2.0, and it still happens on the latest dev (96ae220).

   What I did: ran the TUI on Linux with no host clipboard (no DISPLAY, no WAYLAND_DISPLAY, no clipboard helpers), in a virtual terminal that ignores OSC 52, like VTE. Then I drag-selected some text on the home screen. The recording and screenshot below show the "Copied to clipboard" toast, even though nothing received the text.

   In the same environment, OpenTUI's host clipboard returns unsupported, so the only thing sent was the OSC 52 sequence, with status attempted. As you pointed out, write() in packages/tui/src/clipboard.ts counts that as success, so the success toast is shown. The script below reproduces it.

   I did not test your second point, that the Wayland host backend never retries after it first fails, because that needs a compositor. Related: #50208 (the same false toast over SSH + tmux) and #59052 (the same all-available clipboard setting).

   recording.mp4

   

   Reproduction script (drive.ts)

   // Repro for #59664: TUI shows "Copied to clipboard" although no clipboard received the text.
   // Sandbox: Linux, no DISPLAY / WAYLAND_DISPLAY, no clipboard helpers -> host write can't succeed.
   // The drive's virtual terminal ignores OSC 52 (like GNOME Terminal / VTE).
   import { Effect } from "effect"
   import { OpenCodeDriver } from "opencode-drive"
   
   export default OpenCodeDriver.use(
     {
       ...(process.env.OC_DEV ? { opencode: { dev: process.env.OC_DEV } } : {}),
       tui: { recording: true, pointerOverlay: { leadMs: 180, lingerMs: 700, motionMs: 500, curve: 0.06 } },
     },
     ({ ui }) =>
       Effect.gen(function* () {
         yield* ui.waitFor("Ask anything")
         yield* Effect.sleep("800 millis")
         // Drag-select the "~/files" directory label on the home screen (row 25, cols 13-20)
         yield* ui.mouse({ action: "move", x: 13, y: 25 })
         yield* ui.mouse({ action: "down", x: 13, y: 25, button: "left" })
         yield* ui.mouse({ action: "move", x: 17, y: 25 })
         yield* ui.mouse({ action: "move", x: 20, y: 25 })
         yield* ui.mouse({ action: "up", x: 20, y: 25, button: "left" })
         yield* ui.waitFor("Copied to clipboard")
         yield* ui.screenshot("copied-toast")
         yield* Effect.log(
           `DISPLAY=${JSON.stringify(process.env.DISPLAY ?? "")} WAYLAND_DISPLAY=${JSON.stringify(process.env.WAYLAND_DISPLAY ?? "")} -> no host clipboard exists, yet the toast says "Copied to clipboard"`,
         )
         yield* Effect.sleep("2000 millis")
       }),
   )

   Run it with opencode-drive: opencode-drive run ./drive.ts. It drives opencode from your PATH; set OC_DEV to the path of an OpenCode checkout to run that from source instead.
2. opencode-agent

   added

   reproduced

   on Oct 27, 2026
3. MostDef2000 commented on Oct 28, 2026

   

   MostDef2000

   on Oct 28, 2026

   Author

   More actions

   Follow-up: root cause was on our side — native Wayland copy works; the toast issue stands

   Update after deeper debugging (opencode 2.2.0, same environment). The "host write never fires" observation in the original report was an artifact of our minimal compositor stub, not an OpenTUI/opencode behavior. Two bugs on our side, both fixed:

   1. Blocking backup channel in the compositor stub. The stub ran a blocking urlopen(timeout=6) inline in its single-threaded event loop after each delivery. Any gateway response slower than OpenTUI's 1s host-clipboard timeout (DEFAULT_CLIPBOARD_TIMEOUT_MS = 1_000, host-clipboard.internal.ts) wedged the client backend, whose failed phase is terminal — it never wrote again. The first two copies in a session worked; everything after a slow response died silently.

   2. Missing cancelled event on selection replacement. Our stub did not send the protocol-mandated cancelled to the previous data source when a selection was replaced. OpenTUI's provider pool (wayland.zig: canPublishProvider admits a new provider only while < 2 un-cancelled providers exist per selection type; retireProvider frees a slot only after cancelled AND in-flight transfers completed) then exhausts after exactly two copies — the third copy fails with selectionFailure(.provider) before any network traffic. This part is our protocol non-conformance, not an OpenTUI bug; real compositors send cancelled.

   After fixing the stub, mouse-copy → host clipboard works reliably: 5+ consecutive copies verified in the compositor log, each correctly cancelling the previous, plus interleaved external wl-copy clients.

   What remains valid upstream feedback (the core of this issue):

   • The toast still lies on the failure path. packages/tui/src/clipboard.ts write() resolves success when terminal.status === "attempted" even if host.status is "failed"/skipped — during the wedged period above, every copy showed "Copied to clipboard" while nothing was delivered anywhere (OSC 52 into a VTE terminal goes nowhere). Suggestion: treat a failed host write as a failure (or surface a warning toast) instead of masking it with the terminal "attempted" status.
   • The host backend's failed phase is terminal for the lifetime of the process. A transient compositor stall permanently disables host clipboard writes until the app restarts. Suggestion: allow the backend to recover (retry on the next write, or re-init on display reconnect).

   Happy to provide the stub logs or a minimal non-conformant-compositor reproducer if useful.
4. opencodejr

   marked cli: 'Copied to clipboard' reports success when no clipboard exists in headless tmux session #63514 as a duplicate of this issue on Nov 12, 2026