Repository navigation
Description
Description
WSL2 + WSLg (Ubuntu 20.04, Windows 11). Copy an image on the Windows side, press
ctrl+v in the TUI: no attachment. The first time I got a popup whose text started
with "X11 ..." (I didn't copy the full line); after that the same paste does nothing
at all — no error, no attachment.
Why: the 2.0.29 TUI reads the clipboard through OpenTUI's native host clipboard,
which prefers Wayland. Ubuntu 20.04 ships libwayland-client 1.18.0, which has no
wl_proxy_marshal_array_flags, and OpenTUI's loader in
packages/native/src/clipboard/linux.zig declares that symbol as required (only
fields typed optional are tolerated). So the Wayland backend is dropped entirely
and it falls back to X11. Under WSLg the X11 CLIPBOARD owner is Weston's Xwayland
bridge and it only serves UTF8_STRING, so image/png is refused — that's where the
"X11 clipboard ..." text comes from.
$ dpkg -l libwayland-client0
ii libwayland-client0:amd64 1.18.0-1ubuntu0.1
$ nm -D /lib/x86_64-linux-gnu/libwayland-client.so.0 | grep marshal_array
T wl_proxy_marshal_array
T wl_proxy_marshal_array_constructor
T wl_proxy_marshal_array_constructor_versioned # no ..._flags/mnt/wslg/weston.log while pressing ctrl+v (property OPENTUI_CLIPBOARD is only
used by the X11 backend):
[14:14:33.594] selection request, CLIPBOARD, target image/png, property OPENTUI_CLIPBOARD
[14:14:33.594] can only handle UTF8_STRING targets...
[14:14:33.745] selection request, CLIPBOARD, target image/png, property OPENTUI_CLIPBOARD
[14:14:33.745] can only handle UTF8_STRING targets...
Workaround that works here: give the process a libwayland-client >= 1.20 (I put a
self-contained copy in a private dir and prepend it to LD_LIBRARY_PATH). After
that image paste works and weston.log shows no more OPENTUI_CLIPBOARD requests.
Suggested fix: make wl_proxy_marshal_array_flags optional in the loader, the way
wl_display_set_max_buffer_size already is in the same struct — that file even
documents the convention. Right now one missing symbol silently downgrades image
paste to a code path that can never work under WSLg.
Related, not duplicates:
- tui: all pastes hang after one clipboard read timeout (Linux/Wayland) #50847 same native host clipboard path, but a different symptom (hang after a
read timeout) on Arch/Hyprland. - tui: image paste fails silently on WSL when no clipboard tool is installed (V2) #49895 same WSL "nothing happens", but it assumes the Linux read goes through
wl-paste/xclip. On 2.0.29 it goes through the native host clipboard (as tui: all pastes hang after one clipboard read timeout (Linux/Wayland) #50847
notes), so installing wl-clipboard changes nothing. - NixOS: image paste fails due to missing wayland library path #48931 (closed) NixOS, same "missing wayland library" class. There, adding a
library path was enough because the distro lib was new enough; on Ubuntu 20.04
the system lib is too old, so a newer lib is needed, not just a path.
Plugins
none
OpenCode version
2.0.29
Steps to reproduce
- WSL2 with WSLg, Ubuntu 20.04 (libwayland-client 1.18).
- Open opencode v2 in the TUI.
- Copy an image on the Windows side.
- Press ctrl+v in the prompt.
-> nothing is attached; on some attempts an error popup starting with "X11 " appears.
Screenshot and/or share link
No response
Operating System
Windows 10 + WSL2 (Ubuntu 20.04, WSLg); kernel 6.18.54.1-microsoft-standard-WSL2
Terminal
Windows Terminal
Activity
opencode-agent commentedon Oct 15, 2026
Thanks for the detailed report. I reproduced this on 2.0.29, and it still happens on the latest
dev(4397ee4).What I did:
libwayland-client.so.0from wayland 1.18.0. It has nowl_proxy_marshal_array_flags.wl-copy --type image/png.Results:
[Image 1].LD_LIBRARY_PATH: nothing is attached and no error is shown, on both 2.0.29 and currentdev.This fits your diagnosis that the Wayland backend is dropped when that symbol is missing, and your workaround of loading a newer libwayland. I couldn't reproduce the WSLg-specific X11 half (Xwayland serving only
UTF8_STRING), because there was no X server in my setup. The loader itself lives in OpenTUI, so the fix will likely need to land there.The recording below shows the failing paste with libwayland 1.18 on 2.0.29. The script below reproduces both cases, and its header has the setup steps.
recording.mp4
Reproduction script (drive.ts)
Run it with opencode-drive:
opencode-drive run ./drive.ts. It drivesopencodefrom yourPATH; setOC_DEVto the path of an OpenCode checkout to run that from source instead.native: marshal Wayland requests without libwayland 1.20 (#1846)