Copying in Copilot CLI 1.0.103 updates only tmux’s paste buffer on GNOME Terminal/X11; advertised OSC 52 support prevents working X11 fallback #5258

Summary

Copying selected response text in Copilot CLI 1.0.103 inside tmux on Ubuntu/X11 does not update the system clipboard. The text is available through tmux paste (Ctrl+b, then ]), but pasting into another application with Ctrl+V produces empty or previous clipboard contents.

Copying from ordinary shell panes in the same tmux session works through existing xclip copy-mode bindings.

Inspection and isolated testing of the installed Copilot clipboard code indicate that Copilot trusts tmux's advertised clipboard capability, executes tmux load-buffer -w, and returns system-clipboard success without trying its working local X11 backend. The outer GNOME Terminal/VTE does not complete the OSC 52 clipboard write.

Environment

• Copilot CLI: 1.0.103
• OS: Ubuntu Linux
• Desktop session: X11, not Wayland
• Terminal: GNOME Terminal 3.52.0, VTE 0.76.0
• tmux: 3.4
• Connection: Local desktop session; no SSH, Windows, or WSL
• TERM inside tmux: xterm-256color
• DISPLAY: Set and accessible
• xclip: Installed and working
• Copilot copyOnSelect: true
• Copilot mouse support: Enabled during the original reproduction
• tmux mouse: on
• tmux set-clipboard: external
• tmux allow-passthrough: off

tmux advertises these terminal features:

bpaste,ccolour,clipboard,cstyle,focus,margins,rectfill,title

The advertised clipboard capability does not reflect whether the actual outer terminal completes the OSC 52 operation.

Steps to reproduce

1. Open GNOME Terminal in a local X11 desktop session.
2. Start or attach to tmux with the settings above.
3. Enable automatic copying with copilot config copyOnSelect true.
4. Start Copilot with mouse support enabled.
5. Generate a response and drag-select some response text normally, without holding Shift.
6. Attempt to paste into a separate GUI application using Ctrl+V.
7. Compare with tmux paste using Ctrl+b, then ].

Actual behavior

• The selected text is available in tmux's paste buffer.
• The system clipboard is not updated.
• Copying elsewhere in tmux through existing xclip bindings still works.

Expected behavior

With copyOnSelect=true, selected Copilot response text should reach the system clipboard and paste into other applications.

Successfully populating a tmux buffer should not be treated as proof that the system clipboard was updated.

Direct clipboard-transport reproduction

The transport failure can be reproduced independently of Copilot's selection UI.

Warning: These commands overwrite clipboard contents. Use disposable test text and preserve any clipboard contents you need first.

Inside the affected tmux session:

printf '%s' 'copilot-clipboard-test-123' | tmux load-buffer -w -

Compare the tmux buffer with the system clipboard:

tmux save-buffer -
xclip -selection clipboard -o

The marker appears in the tmux buffer, but not in the X11 CLIPBOARD.

Direct X11 copying works:

printf '%s' 'copilot-clipboard-test-123' |
    xclip -selection clipboard -in

xclip -selection clipboard -o

The marker now appears in the system clipboard.

Installed-code investigation

Read-only inspection of the installed 1.0.103 cli-main.js showed the following effective decision flow. This is a summary, not a verbatim source excerpt:

Inside tmux:
    Probe set-clipboard, allow-passthrough, and Ms capability.

    If set-clipboard is not off and Ms is available:
        Execute tmux load-buffer -w.
        Return "system-clipboard".

    Otherwise, when passthrough is unavailable:
        Populate tmux's buffer.
        Return "tmux-buffer".

The caller tries the local clipboard backend only when
the tmux result is "tmux-buffer" in this local session.

Under the affected configuration, the first branch is selected. The working local X11 backend is therefore skipped.

Isolated test results

The installed clipboard functions were evaluated with the actual bundled cli-native.node module and the running tmux server:

• set-clipboard external, allow-passthrough off:
  The function returned system-clipboard. The tmux buffer contained the marker, but X11 CLIPBOARD did not.
• set-clipboard off, allow-passthrough off:
  Copilot used the local fallback and returned system-clipboard. Both the tmux buffer and X11 CLIPBOARD contained the marker.

This reproduces the backend-routing failure independently of mouse selection. It is not a full end-to-end GUI automation test.

The tmux capability probe is cached in-process, so restart Copilot when comparing configuration changes.

Workaround findings

Temporarily setting tmux's set-clipboard to off, with passthrough already off, allowed the installed Copilot code to use its working local X11 fallback.

That global tmux change was subsequently reverted. Changing shared tmux behavior is not an acceptable permanent requirement for copying from one application.

Other workarounds have limitations:

• Disabling Copilot mouse support sacrifices mouse interaction and does not repair the native clipboard route.
• Shift+drag followed by terminal copy captures rendered screen cells, including wrapping, UI decoration, and potentially neighboring pane content. It is unsuitable for clean multiline copying.
• copyOnSelect=true was already enabled; setting it again does not fix the transport issue.

Suggested fix and regression coverage

Please avoid treating tmux's advertised Ms capability and successful load-buffer -w execution as sufficient evidence of system-clipboard availability.

For a local graphical session with a usable X11 backend, consider using that backend even when tmux advertises clipboard support, rather than letting the tmux transport suppress it.

Suggested regression cases:

• Local X11 with GNOME Terminal/VTE and tmux advertising clipboard support.
• set-clipboard external with allow-passthrough off.
• A working local X11 backend must not be skipped solely because tmux accepts load-buffer -w.
• Remote/headless sessions must retain appropriate terminal-based clipboard behavior.
• tmux-buffer-only success must not be represented as confirmed system-clipboard success.

Regression history

This previously worked for me, but I have not established the last working version or the first affected release.

The changelog mentions a tmux clipboard transport change in 1.0.69. That alone does not establish when this exact failure was introduced.

Related reports, not confirmed duplicates

• ctrl+shift+c no longer copies to clipboard on Linux #2082: Linux clipboard-copying failure.
• Clipboard access doesn't work in vscode -> terminal (WSL) -> screen/tmux #4191: Clipboard works outside tmux but fails inside it in a different environment.
• Copy/Paste broken in Copilot CLI when using SSH inside a tmux session on macOS/Linux → Windows Server 2025 #3260: Copy/paste failure through tmux and SSH to Windows Server.

Why this may be distinct from #3260

Both reports involve clipboard failure when tmux is present, but the reproduction and diagnostic evidence differ:

• Original execution chain in Copy/Paste broken in Copilot CLI when using SSH inside a tmux session on macOS/Linux → Windows Server 2025 #3260: Local terminal -> tmux -> SSH -> Copilot on Windows Server 2025.
• This report's execution chain: Local GNOME Terminal -> tmux -> Copilot on Ubuntu/X11, with no SSH or remote clipboard.
• Original version in Copy/Paste broken in Copilot CLI when using SSH inside a tmux session on macOS/Linux → Windows Server 2025 #3260: 1.0.47; later comments mention other versions.
• This report's version: 1.0.103.
• Root cause in Copy/Paste broken in Copilot CLI when using SSH inside a tmux session on macOS/Linux → Windows Server 2025 #3260: Not established in the issue thread.
• Distinguishing evidence here: Copilot's tmux transport suppresses a working local X11 backend, and that decision was reproduced using the installed clipboard functions.

Similar symptoms and mouse-selection workarounds do not establish a shared root cause. Please treat these reports as related rather than confirmed duplicates unless investigation shows they exercise the same defect. A fix for remote Windows clipboard forwarding would not necessarily resolve this local X11 backend-selection failure.