Paste regression on GNOME Wayland in 1.0.49 (worked in 1.0.48)

[luoqianlin]

Describe the bug

Text paste in the Copilot CLI prompt regressed on Ubuntu GNOME Wayland after upgrading to 1.0.49.

This worked on the same machine with 1.0.48 and earlier, but after updating to 1.0.49, paste inside the Copilot CLI prompt no longer works as expected.

From local investigation, the terminal-level paste path is still functional, but Copilot CLI 1.0.49 appears to trigger clipboard-related code paths that now fail under GNOME Wayland / Mutter with:

writeToClipboard: native clipboard write failed; relied on OSC 52
Failed to get clipboard attachment file path: Error: Failed to get files: Failed to query MIME types:
A required Wayland protocol (ext-data-control, or wlr-data-control version 1) is not supported by the compositor
Failed to write clipboard image to disk: Error: Failed to get image: Failed to query MIME types:
A required Wayland protocol (ext-data-control, or wlr-data-control version 1) is not supported by the compositor

This looks like a regression introduced in 1.0.49: the same environment did not show these errors on 1.0.48.

Affected version

GitHub Copilot CLI 1.0.49

Steps to reproduce the behavior

1. Use Ubuntu GNOME on Wayland.
2. Open GNOME Terminal.
3. Start copilot.
4. Try pasting text into the prompt.
5. Observe that paste inside Copilot CLI no longer behaves correctly after upgrading to 1.0.49.
6. Inspect ~/.copilot/logs/process-*.log and observe repeated Wayland clipboard protocol errors.

Expected behavior

Text paste in the Copilot CLI prompt should continue to work on GNOME Wayland as it did in 1.0.48, without attempting clipboard operations that fail because of unsupported compositor protocols.

Additional context

Environment:

• OS: Ubuntu 24.04.4 LTS
• Session: Wayland
• Desktop: GNOME
• Terminal: GNOME Terminal
• Input method: fcitx5
• Copilot CLI:
  • 1.0.48: worked
  • 1.0.49: broken

Notes from local investigation:

• copilot points to the real binary, no shell wrapper involved.
• PreeditEnabledByDefault=False in fcitx5 was already set for a separate preedit visibility workaround; changing it does not fix this paste regression.
• Injecting bracketed paste sequences manually into the TTY still inserts text, which suggests the underlying terminal paste path still exists.
• The regression seems tied to new clipboard handling introduced or exercised by 1.0.49, not to a general terminal paste failure.

Relevant local evidence:

• 1.0.43: no related clipboard / Wayland protocol errors in logs
• 1.0.48: no related clipboard / Wayland protocol errors in logs
• 1.0.49: repeated Failed to get clipboard attachment file path / writeToClipboard / A required Wayland protocol ... errors

Potentially related issue:

• Copy stops working on 1.0.49. Works fine on 1.0.48 #3395 Copy stops working on 1.0.49. Works fine on 1.0.48

[luoqianlin]

Follow-up after inspecting the packaged implementation in more detail.

I could not inspect the full application source from the public repo because the repository currently exposes mainly the public docs/changelog/install artifacts, so I diffed the published npm packages for @github/copilot instead.

What I found:

1. The top-level JS call sites are already present in both 1.0.48 and 1.0.49.
   In the packaged app.js, both versions already contain the same clipboard-related calls:

   • new e.ClipboardManager().getFiles().at(0)
   • new e.ClipboardManager().getImageData().data
   • a.setClipboardText(t)
   • a.setClipboardContents({availableFormats:["text","html"], ...})

   So this does not look like the prompt/input UI suddenly started calling totally new clipboard code only in 1.0.49.

2. The significant change is the bundled native clipboard dependency.
   In the npm package:

   • 1.0.48 bundles @teddyzhu/clipboard 0.0.5
   • 1.0.49 bundles @teddyzhu/clipboard 0.0.10

3. The Linux native clipboard module changed substantially between those versions.
   The bundled Linux x64 native module changed from:

   • 1.0.48: 1708960 bytes
   • 1.0.49: 2242912 bytes

   with different checksums as well, so this is not just metadata churn.

4. The new native module in 1.0.49 clearly embeds a Wayland clipboard implementation that depends on wl-clipboard-rs and the data-control protocols.

   Strings present in the 1.0.49 native module but absent from the 1.0.48 one include:

   • wl-clipboard-rs-0.9.3/src/copy.rs
   • wl-clipboard-rs-0.9.3/src/paste.rs
   • ext-data-control, or wlr-data-control
   • A required Wayland protocol (
   • Failed to query MIME types:

   The same binary also contains:

   • zwlr_data_control_manager_v1
   • wayland-client
   • wayland-protocols

5. This matches the runtime errors I see locally on Ubuntu GNOME Wayland / Mutter:

Failed to get clipboard attachment file path: Error: Failed to get files: Failed to query MIME types:
A required Wayland protocol (ext-data-control, or wlr-data-control version 1) is not supported by the compositor

Current conclusion:

• The regression is most likely caused by the upgrade of the bundled native clipboard backend in 1.0.49, not by a generic terminal paste/input regression.
• On GNOME Wayland / Mutter, the newer backend appears to exercise a native Wayland clipboard path that depends on ext-data-control / wlr-data-control.
• That protocol requirement was not present (or at least not exercised the same way) in the 1.0.48 bundled clipboard backend.

So the most plausible root cause is:

1.0.49 upgraded the bundled native clipboard library, and that newer Linux/Wayland backend now fails on GNOME Mutter because it requires data-control protocols that are not available there.

Potentially relevant issue:

• Copy stops working on 1.0.49. Works fine on 1.0.48 #3395 (Copy stops working on 1.0.49. Works fine on 1.0.48)

[tz-calumino]

# GitHub Copilot CLI clipboard workaround for Wayland environments.
#
# Some Wayland compositors do not support the clipboard protocols
# required by Copilot CLI (ext-data-control / wlr-data-control),
# which causes errors such as:
#
#   "Failed to write clipboard content"
#   "Couldn't connect to the Wayland compositor"
#
# This wrapper forces Copilot CLI to use the X11 clipboard path
# instead of the broken/incompatible Wayland clipboard backend.
#
# Requirements:
#   sudo apt install xclip wl-clipboard
#
# Add this function to ~/.bashrc and reload with:
#   source ~/.bashrc

copilot() {
    env -u WAYLAND_DISPLAY \
        -u WAYLAND_SOCKET \
        XDG_SESSION_TYPE=x11 \
        DISPLAY=${DISPLAY:-:0} \
        /home/$USER/.local/bin/copilot "$@"
}

[StefanRehder]

Additional affected environment: Nobara 43 (Fedora-based) + Ghostty + GNOME Wayland

Still broken in 1.0.54 on the following system:

Environment:

• OS: Nobara 43 (Fedora 43-based)
• Kernel: 7.0.5-200.nobara.fc43.x86_64
• Session: Wayland (XDG_SESSION_TYPE=wayland, WAYLAND_DISPLAY=wayland-0)
• Desktop: GNOME
• Terminal: Ghostty 1.3.1
• Copilot CLI: 1.0.51 → still broken in 1.0.54
• wl-clipboard 2.2.1: installed (confirmed wl-paste reads image/png correctly)

Symptom:
Screenshot taken with Print Screen key cannot be pasted into the Copilot CLI prompt. The image is confirmed to be in the Wayland clipboard (wl-paste --list-types shows image/png), but Copilot CLI fails to read it.

Log errors (from ~/.copilot/logs/process-*.log):

[ERROR] Failed to get clipboard attachment file path: Error: Failed to get files: Failed to query MIME types: A required Wayland protocol (ext-data-control, or wlr-data-control version 1) is not supported by the compositor
[ERROR] Failed to write clipboard image to disk: Error: Failed to get image: Failed to query MIME types: A required Wayland protocol (ext-data-control, or wlr-data-control version 1) is not supported by the compositor
[WARNING] writeToClipboard: native clipboard write failed; relied on OSC 52: 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

Root cause (from code inspection):
The @teddyzhu/clipboard native module (bumped from v0.0.5 in 1.0.48 to v0.0.9/v0.0.10 in 1.0.51+) attempts to use the zwlr-data-control or ext-data-control Wayland protocols directly. GNOME's Mutter compositor does not expose these protocols — they are only available in compositors like sway/wlroots. The old v0.0.5 did not include Linux .node binaries so it fell back to wl-paste/xclip, which worked. The new version uses the native binding but it fails on GNOME Wayland.

Workaround:
Use @ ~/Pictures/Screenshots/<filename>.png to attach images instead of pasting.