ctrl+shift+c no longer copies to clipboard on Linux

Describe the bug

Pressing ctrl+shift+c copies selected text to the clipboard in almost all linux terminal sessions on Ubuntu 24.04.
As of at least v1.0.4 of the github copilot CLI, this shortcut no longer works.
I saw that the ctrl+c adn right click now can be used for copying selected text, but for that to work, I have to 1. Have xclip installed, and 2. re-learn the keyboard shortcut for only the github copilot CLI or move to the mouse. Both of these are unacceptable compromises for a solution that used to work.
edit: ctrl+shift+v is still the shortcut to paste in to Copilot CLI, so it makes even less sense for ctrl+shift+c to be broken

Affected version

GitHub Copilot CLI 1.0.5.

Steps to reproduce the behavior

Open copilot CLI
Select any text
press ctrl+shift+c
attempt to paste in another program - nothing happens.

Expected behavior

Text is copied when pressing ctrl+shift+c and can be pasted in another terminal

Additional context

No response

If you want the old behavior, you can set mouse to false in your ~/.copilot/config.json.

@tpope

@tpope Thanks for the suggestion, but unfortunately I don't think that's a good solution, as it breaks the ability to scroll back through the conversation with the mouse wheel.

You can hold down shift in most terminals to temporarily bypass mouse reporting and select text.
You can use a terminal that supports sending shift+ctrl+c to the terminal application (Ghostty, maybe others). Using a terminal with OSC 52 support (many terminals support it) will also eliminate the xclip requirement.

@tpope

@tpope I'm sure there are an infinite number of workarounds. That doesn't change my opinion that this is a bug that needs fixing. It broke functionality that existed for many versions and surprises the Linux power user by removing a common terminal feature.

same story here :/

Same here

If you want the old behavior, you can set mouse to false in your ~/.copilot/config.json.

Thanks, it works. But it is useless because what I want to copy requires scrolling up. Any tip to enable the old scrolling behaviour ?

ctrl+c to copy doesn't seems quite right. Especially when it's the SAME command used to exit the CLI.

How many times do we execute the command twice or more in a row just to make sure we actually copied a selected text? In my case, at least twice. Sometimes more. In fact, I already happened to me: I ended up exiting the CLI session.

For someone so used to copy and paste in terminal mode using ctrl+shift+c to copy is what it feels "right".

EDIT: Added last sentence.

Related this has also broken my 'middle-click' to paste I use with MobaXterm, which is derived from PuTTY. I don't have this kind of behavior with Claude, Codex, or Gemini.

I have experienced the same issue. This issue makes Copilot CLI almost unusable.

For those of you who came to this bug looking for a potential solution.

It appears that the Copilot CLI uses an OS based application called wl-clipboard which may not be installed out of the box on Ubuntu ARM based installations. I may have missed this detail somewhere in the CLI documentation

sudo apt-get install wl-clipboard

This app with a text selection and a right mouse click allowed the C+P to work properly.

Hey I'm running copilot cli in a container, and it's now unusable because it blocks me from interacting with the text.

Update: This fixed it for me
sudo apt install -y xclip

Original:
This is certainly annoying and making it hard to use. Can't copy nor summaries, nor commands, and when trying the control+c / right-click, either close by accident or nothing happens...

Update: This fixed it for me sudo apt install -y xclip

Original: This is certainly annoying and making it hard to use. Can't copy nor summaries, nor commands, and when trying the control+c / right-click, either close by accident or nothing happens...

this did not fix it for me (Ubuntu 25.10, copilot cli v1.0.21)

sudo apt-get install wl-clipboard

this worked

If you want the old behavior, you can set mouse to false in your ~/.copilot/config.json.

this works for me, however not being able to scroll chat sessions is a killer, bug still present in v1.0.27

same story here :/

guys, I have asked Claude Sonnet 4.6 how to fix this, it was thinking for a while and suggested to install kitty terminal, install some additional libraries and it works like a charm. Good luck ;)

work around: open the chat session in VS Code. copy/pate from there

@tpope

It does work in Kubuntu + Konsole + zsh with holding down SHIFT, as @tpope mentioned (thanks!)

hold down SHIFT and select text (I see a different selection color)
do not scroll
release shift
Ctrl+Shift+C - and the text is copied

You can hold down shift in most terminals to temporarily bypass mouse reporting and select text.

You can use a terminal that supports sending shift+ctrl+c to the terminal application (Ghostty, maybe others). Using a terminal with OSC 52 support (many terminals support it) will also eliminate the xclip requirement.

The trick is indeed to hold down SHIFT while selecting with the mouse AND while then copying it (so shift+ctrl+c).
Very un-intuitive. Very much NOT documented in copilot's own help.

Pressing Shift while selecting with mouse works.

The trick is indeed to hold down SHIFT while selecting with the mouse AND while then copying it (so shift+ctrl+c).
Very un-intuitive. Very much NOT documented in copilot's own help.

Thank you, this indeed solved it for me, although it's still a bit disappointing that this bug was introduced now already quite a few versions ago and it's still there. It used to work fine.

Fix this. If I right click and Copilot says "copied to clipboard", it should be copied to clipboard. Not the opposite.

No undocumented tricks or hacks please.

Root cause: On GNOME/Wayland, Copilot CLI's bundled native clipboard module ( wl-clipboard-rs ) fails because Mutter doesn't implement the wlr-data-control protocol. The CLI's OSC 52 fallback also silently failed since GNOME Terminal disables OSC 52 writes by default. Both failures were swallowed silently, so the UI reported "copied" despite nothing landing on the clipboard (there is no way for a CLI util to check whether OSC 52 is successful).

• Workaround: CLI also tries running wl-copy from the wl-clipboard package, so install that and the /copy, ctrl+c, and right click copy will work.

You could also enable OSC 52 in gnome terminal (if that is what you use). However, the reasons that OSC 52 and wlr-data-control are not implemented / turned off is for security reasons:

Any program that can write to your terminal's stdout — including a malicious script you run, output from cat-ing an untrusted file, or even text from a remote SSH session/tmux pane — can inject the raw escape sequence \x1b]52;c;\x07 and silently overwrite your system clipboard. clipboard hijacking — swap in a malicious shell command disguised as something else, hoping you paste-and-run it later.

The above should really be explained when running /terminal-setup. Maybe it should make a test and ask the user whether it works.

Even if they implemented ctrl+shift+c, which would be very nice indeed, it would still require the above wl-copy to work.

You can hold down shift in most terminals to temporarily bypass mouse reporting and select text.

You can use a terminal that supports sending shift+ctrl+c to the terminal application (Ghostty, maybe others). Using a terminal with OSC 52 support (many terminals support it) will also eliminate the xclip requirement.

The trick is indeed to hold down SHIFT while selecting with the mouse AND while then copying it (so shift+ctrl+c). Very un-intuitive. Very much NOT documented in copilot's own help.

Thank you, you are the best!!!

Navigation Menu

Repository navigation

ctrl+shift+c no longer copies to clipboard on Linux #2082

Describe the bug

Affected version

Steps to reproduce the behavior

Expected behavior

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ctrl+shift+c no longer copies to clipboard on Linux #2082

Description

Describe the bug

Affected version

Steps to reproduce the behavior

Expected behavior

Additional context

Activity

tpope commented on Mar 16, 2026

MasonMcV commented on Mar 17, 2026

tpope commented on Mar 17, 2026

MasonMcV commented on Mar 18, 2026

bartoszkrawczykunivio commented on Mar 19, 2026

StefanoBraghetto commented on Mar 20, 2026

roperi commented on Mar 21, 2026

roperi commented on Mar 21, 2026

JohnVillalovos commented on Mar 22, 2026

jinbo-huang commented on Mar 26, 2026

morgangraphics commented on Mar 30, 2026

menno-snom commented on Apr 2, 2026

IanRiera commented on Apr 2, 2026

enrico-mi commented on Apr 9, 2026

binhex commented on Apr 15, 2026

bartoszkrawczykunivio commented on Apr 15, 2026

chrisplusplus commented on Apr 23, 2026

binary-data commented on May 7, 2026

loorschot-qvantel commented on Jun 4, 2026

sedat-eyuboglu commented on Jun 9, 2026

andrea-dauria-sony commented on Jun 10, 2026

credmond commented on Jun 26, 2026

runephilosof commented on Jul 13, 2026

jaredxfeng commented on Aug 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions