While rewriting my Emacs configuration for a pure terminal usage (no X/Wayland) I discovered the ANSI escape sequence 52 to read-from and write-to the system clipboard. Soon after, I found out how such a simple feature was causing so much discussion in Linux terminal’s issues trackers and how scattered its support was.
Copy & Paste
Writing (copying to) and reading (pasting from) the system clipboard are two actions we make every day, even several times per minute (if you are a programmer).
Ctrl+C and Ctrl+V are the ubiquitous short-cuts supported by all Desktop Environments.
Such operations are so straightforward we do not even think about them, we just press the keys using muscle memory.
Almost all applications support them with an exception - terminal emulators.
If you press Ctrl+C in a terminal, it will send the signal number 2 (SIGINT) to terminate the running process.
For this reason, most terminal emulators bind the alternatives Ctrl+Shift+C and Ctrl+Shift+V sequences to the copy & paste action.
The need for an escape sequence
Apparently, an ANSI escape sequence to copy & paste text from the terminal seems superfluous, but it is not.
Terminal-based editors provide advanced ways of handling text using many different commands.
Take Emacs as an example, it has the concept of kill ring and more than 12 different short-cuts to cut (kill), copy, and paste (yank) text: press C-k to cut a line, C-w to cut from the cursor to the mark, C-w to cut the selected region, M-w to copy it, …
As you can see, the above commands use different short-cuts so when you copy a piece of text inside the editor, it will not be available in your Desktop clipboard automatically.
For example, you can not copy a word from a file you are editing and paste it in the browser search bar.
In Emacs you can use the Clipetty minor mode to integrate your kill ring with the system clipboard using OSC 52 codes.
This is one of the reasons behind the need for an escape sequence that allow a terminal emulator to write to your clipboard.
Please give me a non-emacs use case
The use case of copying something from a terminal editor to the clipboard is not only related to Emacs. Vim has a OSC 52 plugin, NeoVim supports it natively and even GNU nano can handle it. Terminal multiplexers like tmux or GNU screen support that feature too.
The ability to copy a piece of text from a terminal to your clipboard is useful. Moreover, if you are connected to a remote server through ssh could be necessary. A single line of text, the output of a command, the content of a file, how do you copy them from a terminal?
OSC 52
The Operating System Command 52 escape code was introduced by Xterm decades ago and it is still the standard way to read-from and write-to the system clipboard. It works in a very simple way but requires the support from the terminal emulator. When a specific escape sequence is executed, the terminal intercept it and, acting like a proxy, forwards the action to the Display Server (e.g Wayland) If the terminal does not recognize the sequence, executing the escape code will not do anything. The following examples only work if your terminal emulator supports OSC 52 sequences (fully or partially, as we will see in a moment).
Reading from the clipboard
Running printf '\e]52;c;?\e\\' in a terminal will read the content of your system clipboard and print it in base64.
$ printf '\e]52;c;?\e\\'
$ 52;c;VGhpcyBpcyBhbiBleGFtcGxl
The VGhpcyBpcyBhbiBleGFtcGxl string is the base64 representation of the string This is an example I copied before with Ctrl+C in another application.1
The other characters are the escape sequence response structure.
Writing to the clipboard
The escape sequence for writing to the clipboard is similar to the previous one, but you need to pass a base64 string to copy.2
$ TO_CLIP=$(echo 'hello'|base64)
$ printf "\e]52;c;%s\a" "$TO_CLIP"
Once executed, your clipboard last item will be the hello string and the short-cut Ctrl+V will paste it in any application running in your system.
A dangerous method
Allowing any application running in your terminal to read from the system clipboard seems dangerous. Your clipboard could contain an API key, a password, a secret message… We type sensitive information like these every day in our terminals, so this is not a good reason to not support OSC 52.
Should we avoid using sudo because it grants unlimited power to an application?
Should we avoid using external software dependencies because of the supply-chain attacks?
Should we avoid using knives because they are sharp?
We do a lot of dangerous things every day because we know how to deal with them safely.
For example, when we use sudo a password is required to confirm the risky action.
Some terminal emulators, like Kitty, follow this approach and, when a OSC 52 sequence is executed, ask the user a very simple question.
A program running in this window wants to read from the system clipboard. Allow it to do so, once? Yes/No
I am the user, I know what I am doing, I asked for it, inform me and let me choose.
Without this premise there will be no personal computing.
A confirmation or an explicit terminal configuration (e.g. Xterm allowwindowops) is all we need to use OSC 52 sequences safely.
On the other hand, allowing an escape sequence to write to your system clipboard it is much safer.
The most dangerous thing that could happen is accidentally overwriting a text you copied before.
This is a common situation, especially if you work at your keyboard very fast.
Do we really need a confirmation prompt every time we hit a Ctrl+C-like short-cut?
Just a copy
The dangerous read-from-clipboard OSC 52 method is also the less useful because, in graphical environments, you can just press Ctrl+Shift+V and paste the clipboard content in your terminal without the need of an escape sequence.
It is the Desktop Environment that will handle it for you and pass the clipboard content to the application (the terminal in our case).
So the most useful OSC 52 method is the write-to-clipboard one because you need it to achieve a seamless integration of you terminal applications with your Desktop.
This feature is supported by terminal emulators on many platforms such as iterm2 on macOS and the new terminal on Windows.
Linux Terminal Emulators support for OSC 52
All these Linux Terminal Emulators support at least OSC 52 write (copy to clipboard) feature (link to relevant doc pages):
Have you spotted some missing terminals from the list? Where are the leading Desktop Environments’ default terminals?
KDE and Konsole
The default KDE terminal emulator is Konsole. A feature request for OSC 52 support in Konsole was created in 2016 and it took 8 years to be completed. The 37-lines-long-commit with the write-to clipboard support was pushed in 2024. Better late than ever.
Gnome and the three terminals
Gnome is the most popular Linux Desktop Environment - it is the default on Ubuntu, Fedora and many others. In 2026 Gnome has three “default” terminal emulators:
- Gnome Terminal, the oldest one
- Gnome Console, the modern one
- Ptyxis, the modern one - developers oriented
None of them support OSC 52, not even Ptyxis. The reason is simple - they all depend on VTE, the Gnome Virtual Terminal library, and they do not want to add a custom core feature on top of it. The VTE discussion around OSC 52 support has been going on since 2018 and, in 2026, it is still open. Despite the many other terminals’ implementations of OSC 52, the VTE project seems to be concerned by security issues.
Meanwhile, users (like me) are switching to other terminals with OSC 52 support. Is this the safety goal they want to achieve?
The bottom line
Almost all terminal emulators support the OSC 52 escape sequences. They do it safely using different security frameworks based on user confirmation, static configuration, temporal authorization and so on. It is disappointing that the most popular Linux Desktop Environment does not support it in the default terminal application used by millions (Gnome Console). The same is true for the default terminal (Ptyxis) of popular developers oriented distributions like Fedora.
As one user in the VTE issue said:
Making user experience terrible for the sake of solving imaginary problems that do not exist in the real world scenarios can hardly be considered “proper security implementation”. It’s more like locking a salt shaker in a canteen in a steel safe for fear someone might be poisoned to death by the salt.
So please let me use the default terminal emulator to run my Emacs without forcing me to install another dangerous application that will access my entire system.3
Related resources
The Arch Linux Wiki has a page that describe how Linux Clipboard works.
The wl-clipboard tool allows you to read and write the Wayland clipboard (it is available in most repositories).
The general purpose command line tool called osc allows you to read-from and write-to the clipboard on any system (using a proper terminal).
A bash one-liner function to use when needed: echo "Hello" | osc52 to copy a string, cat file.txt | osc52 to copy a file, ls -la | osc52 to copy the command output.
Did you know that Emacs has a
base64-decode-regioncommand to decode the selected string? ↩︎Emacs
M-x base64-encode-regionwill encode the selected text to base64. ↩︎If you search the web for “gnome terminal support osc52”, you will find a long list of disappointed users saying “I switched to…”. ↩︎