Bug: /copy still fails on GNOME/Mutter Wayland in 1.0.80 — xclip fallback wrongly gated on WAYLAND_DISPLAY being unset

Describe the bug

/copy fails on GNOME/Mutter Wayland sessions with:

Failed to copy to clipboard: Error: Failed to set text: Failed to write clipboard content:
A required Wayland protocol (ext-data-control, or wlr-data-control version 1) is not
supported by the compositor

This was previously reported in #3395, #3414, #3467, #3483, #3586 and closed as fixed in 1.0.69 ("Make /copy fall back to wl-copy on Wayland", agent-runtime PR #12146). That fix does not resolve the issue for GNOME/Mutter users, because:

1. GNOME/Mutter (all versions up to and including Mutter 46, shipped in Ubuntu 24.04 LTS) does not implement wlr-data-control, and only gained (opt-in) ext-data-control-v1 support in Mutter 47+. So the new wl-copy fallback still fails with the same underlying error on GNOME 46.
2. Inspecting the bundled CLI JS (v1.0.80, linux-x64), the xclip fallback path is gated by:

   function SUe(){return process.platform==="linux"&&!!process.env.DISPLAY&&!process.env.WAYLAND_DISPLAY}
   

   This requires WAYLAND_DISPLAY to be unset, which is never true in a native Wayland session — even though xclip (via XWayland) works correctly and is already installed on the system. As a result, the CLI never attempts the one fallback that actually works on GNOME.

Affected version

GitHub Copilot CLI 1.0.80 (bug present since at least 1.0.49; the 1.0.69 changelog fix did not address it).

Environment

• OS: Ubuntu 24.04.4 LTS
• Desktop: GNOME Shell 46.0 (Mutter 46), Wayland session
• DISPLAY=:0, WAYLAND_DISPLAY=wayland-0
• xclip installed and confirmed working manually (echo test | xclip -selection clipboard succeeds and is readable)
• wl-copy (wl-clipboard) fails as expected, since Mutter 46 lacks the required protocol

Steps to reproduce

1. Run Copilot CLI on Ubuntu 24.04 in the default GNOME Wayland session.
2. Run /copy (or select text and try to copy).
3. Observe the error above; nothing is copied to the clipboard.

Expected behavior

/copy should successfully copy to the clipboard. Since the compositor-level Wayland protocols are unavailable, the CLI should fall back to xclip/xsel (which work via XWayland regardless of WAYLAND_DISPLAY being set) before giving up, or fall back further to OSC 52.

Workaround found

Launching the CLI with WAYLAND_DISPLAY unset (env -u WAYLAND_DISPLAY copilot) causes the xclip fallback to trigger and /copy works correctly. This confirms the fix is simply to stop gating the xclip fallback on the absence of WAYLAND_DISPLAY.

Suggested fix

In the clipboard-writing logic, attempt xclip/xsel as a fallback whenever the executable is present and DISPLAY is set, regardless of WAYLAND_DISPLAY. Reserve WAYLAND_DISPLAY checks only for deciding whether to also try wl-copy/native Wayland protocols first.

Additional context

This is a regression/gap that has been reported and closed multiple times without a working fix for GNOME/Mutter users specifically (a large fraction of Linux desktop users, since GNOME is Ubuntu's default). Please consider reopening rather than closing as duplicate, since the root cause (the xclip gating logic) has not actually been changed in any release through 1.0.80.

Start at the /copy entry point and trace the clipboard-writing logic represented by the bundled CLI JS, especially the fallback condition that checks DISPLAY and WAYLAND_DISPLAY. Verify the behavior in a GNOME/Mutter Wayland session with xclip installed, then confirm that clipboard copying succeeds while Wayland-native protocols remain unavailable.