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.

從 /copy 入口開始，追蹤由隨附的 CLI JS 所表示的剪貼簿寫入邏輯，尤其是檢查 DISPLAY 和 WAYLAND_DISPLAY 的 fallback 條件。在已安裝 xclip 的 GNOME/Mutter Wayland 工作階段中驗證其行為，然後確認剪貼簿複製成功，同時 Wayland 原生協定仍不可用。