feat(osc52) clipboard by dezza · Pull Request #20896 · vim/vim

dezza · 2026-07-31T12:12:52Z

Just letting you know I am still working on this, thus leaving this for input.

I have spend time polishing and minimizing the tiny version, but have everything else implemented for normal,huge, but I need to merge it into my new base and its getting late.

Issue: #19441

Plan:

Configure, Feature

[ --enable-osc52[=OPTS] (not supported with --enable-gui)

OSC 52 Clipboard [default=yes] [OPTS=no/yes/only]], , enable_osc52="no")

(*default=yes means --enable-osc52 without explicit =yes|only choice)

yes

enables FEAT_CLIPBOARD_OSC52 (and FEAT_CLIPBOARD_OSC52_TINY if built on tiny.)

only

disables x11,wayland in configure making a super minimal clipboard terminal setup.

What lacks in tiny:

Detection
- osc52 via DA1 and XTGETTCAP
- ssh
- tmux
- screen
  (also useful for clipboard syncronization)

When enabled :version:

+osc52
+clipboard

Because the features are similar to regular clipboard but it does not have clipboard_provider etc. All other code is bypassed, it does not enable FEAT_CLIPBOARD it just shows the feature as it is otherwise fully compatible with the provided features.

Environment variable

(most relevant to tiny version, but also works on regular build)

VIMOSC52=1, enables "+, and "* registers loading content at startup from OSC52 p,c primary/clipboard

Why env var?

Functions as an entrypoint for your regular sysadmin/devops who have no readwrite access/forbidden to customize config and just want clipboard working remotely on servers he trusts.

Integration with `clipboard.c` on regular build

Current suggestion is that it defaults to wayland,x11,osc52 if built with --enable-osc52=yes.

If VIMOSC52=1 is used on regular build it reorders clipmethod to

clipmethod=osc52,wayland,x11

Meaning it prioritizes it first. Same argument as described above for tiny; make the feature extremely accessible to anyone; even system admins who never really configures vim.

vimrc configuration is an explicit, non-default - ordered to your liking.

set clipmethod=osc52,wayland,x11

Configuration is explicit, non-default, always for this feature.

Doc

options.txt (--enable=only not listed here as all other backends disabled)

                                                *'clipmethod'* *'cpm'*
 'clipmethod' 'cpm'     string  (default for Unix: "wayland,x11",
                                with OSC 52: "wayland,x11,osc52",
                                 for VMS: "x11",
                                 otherwise: "")
                        global
                        {only when the |+xterm_clipboard|, |+wayland_clipboard|,
                       or |+eval| features are included}
                       |+osc52| or |+eval| features are included}
        Specifies which method of accessing the system clipboard (or clipboard
        provider) is used.  Methods are tried in the order given; the first
        working method is used.  Supported methods are:
                wayland         Wayland selections
                x11             X11 selections
                osc52           OSC 52 terminal clipboard.
                               {only non-gui when compiled with |+osc52|}
                               See |clipboard-osc52|.
                <name>          Use a clipboard provider with the given name

        Note: This option is ignored when either the GUI is running or if Vim
       is run on a system without Wayland or X11 support, such as Windows or
       macOS.  The GUI or system way of accessing the clipboard is used
       instead, meaning |v:clipmethod| will be set to "none".  The
       is run on a system without Wayland, X11, or OSC 52 support, such as
       Windows or macOS.  The GUI or system way of accessing the clipboard
       is used instead, meaning |v:clipmethod| will be set to "none".  The
        exception to this is the |clipboard-providers| feature, in which if
        a clipboard provider is being used, then it will override the existing
        clipboard functionality.

term.txt


                                                       *osc52-clipboard*
OSC 52 provides terminal-mediated access to the clipboard, including over
SSH.  See |clipboard-osc52|.

                                                        *xterm-command-server*
 When the X-server clipboard is available, the command server described in
 |x11-clientserver| can be enabled with the --servername command line argument.
    *+clipboard*                |clipboard| support compiled-in
    *+clipboard_working*        |clipboard| support compiled-in and working
    *+clipboard_provider*  |clipboard-providers| support compiled-in
    *+osc52*            OSC 52 terminal clipboard support compiled-in

Detection

DA1 and XTGETTCAP Ms is supported in regular builds.

Additional notes

Timeouts, performance

In my draft for regular builds it is thus with timeout on reading:

long       timeout = term_osc52_is_ssh() ? 250L : 100L;

250ms over ssh, 100ms on regular PC.
(non-blocking btw)

In my testing 10MB clipboard on a Ryzen 7900 finishes as fast as 31ms, quite impressive.

head -c 10M /dev/zero | tr '\0' x

Thus it is also extremely unlikely to fail unless OOM, all-core workload, or over ssh.

It is more likely that a wayland or x11 connection will trip requiring :wlrestore, :xrestore in my experience.

I don't think there are reliable probes into system loadavg that can scale with loadavg, nor do I think network provides a similar probe of performance, however one could scale with the highest recorded timeout over a flaky ssh connection - always expecting output on the other side.

As soon as it receives first byte, it knows that there is actually coming data and can increase timeout sensibly.

I am biased to sensible defaults, basically no configuration and scaling timeout if done correctly.

For errors/warning I am considering if these are sufficient for regular build.

								*W23*
When you are yanking into the "* or "+ register and Vim cannot establish a
connection to the X11 selection (or clipboard), it will use register 0 and
output a warning:

  Warning: Clipboard register not available, using register 0 ~

Note: This also applies to the Wayland clipboard feature as well.

								*W24*
Vim comes in different flavors, from a tiny build, that just tries to be
compatible to original Vi, to enhanced builds which include many improvements
(like a GUI).  However, on servers and embedded systems, Vim is typically
compiled without clipboard support, since this feature requires X11 libraries
to be present.  Check the ":version" output for the flag |+clipboard| or
-clipboard.  The former means clipboard support is present while the latter
means your Vim does not contain clipboard support.

In the case when you are trying to access the "* or "+ register and Vim has
no clipboard support, you will see this warning:

  Warning: Clipboard register not available. See :h W24~

If you have a vim with no clipboard support but would like to use the
clipboard, try to install a more enhanced Vim package like vim-enhanced or
vim-gtk3 (the gui packages usually also come with a terminal Vim that has
clipboard support included).

Security

Its not enabled by default for neither configure nor vimrc and if you have reading enabled in your terminal emulator there are plenty of attack vectors already, vim is not the only one - you could have one waiting for you in .bashrc 🤥

Imho, if anyone should filter osc52 it should be .ssh/config similar to how X11Forwarding= is as toggle, but they will probably point at terminal emulators; even if they chose to support the now fading x11 support.

Make base64 functions and args independent from vimscript and its blob_T type.

Add following to `feature.h` to test. diff --git a/src/feature.h b/src/feature.h --- a/src/feature.h +++ b/src/feature.h @@ -1003,6 +1004,10 @@ */ #if defined(HAVE_TGETENT) # define FEAT_TERMRESPONSE +# define FEAT_CLIPBOARD_OSC52 +# ifndef FEAT_CLIPBOARD +# define FEAT_CLIPBOARD_OSC52_TINY +# endif #endif

64-bitman · 2026-07-31T15:40:35Z

+dnl OSC 52 clipboard support.
+AC_MSG_CHECKING(--enable-osc52 argument)
+AC_ARG_ENABLE(osc52,
+ [  --enable-osc52[=OPTS]     OSC 52 Clipboard [default=yes] [OPTS=no/yes/only]], , enable_osc52="no")


I don't think we need a feature flag for this in my opinion. This feature is small and requires no dependencies

Not +osc52 in version? or do u mean the FEAT_ vars? If not enabled its good to check in version as its non-default.

I meant the FEAT_ vars. However this would make +clipboard permanently enabled, which may confuse people, so I am not sure

Reason for the 2 vars _TINY and regular is because its vastly different in impl - one is literally enabling system clipboard registers raw and minimal (this state of commits).

Reason for the _ONLY var was same, maybe it can be inferred from -wayland,-x11 I can look into it.

It also needs to avoid not doing lots if !FEAT_CLIPBOARD cuz there are way too many.. it completely avoids that now.

64-bitman · 2026-07-31T15:44:50Z

I don't see any code integrating this with clipmethod option. Is that planned?

dezza · 2026-07-31T16:39:53Z

I don't see any code integrating this with clipmethod option. Is that planned?

I have it, I was switching pc a lot at the time due to warranty of part.

So yes, clipmethod, and provider is impl, I just have not grabbed it from alternative pc yet.

chrisbra · 2026-08-01T10:18:35Z

thanks for working on this and thanks for careful thinking of exfiltration attacks. Assuming enabling osc52 handling does not add much code for vim tiny, wouldn't it be much more useful to always enable this for tiny builds, instead of giving distributions the choice to disable it for their own tiny vim? It would still have to be explicitly enabled by users during runtime, and I don't see why distributions would need to disable it.

On another point, how well is OSC52 actually supported by terminals nowadays? I read that writing to the clipboard is even more widely supported than reading the clipboard by terminals (for the same security concerns)? Is that true?

And finally, I am not so sure the $VIMOSC52 is a good choice. I think we should instead make use of :set clipmethod even in tiny mode, so that users can selectively enable and disable the feature as they need it. This means you could set it interactively or via a command line argument --cmd 'set clipmethod=osc52' in case you are not allowed to add config files on remote servers or containers. However I am not sure how complicated would it be to just promote the clipmethod=osc52 for tiny builds and how much additional code this would add. (This likely means decoupling HAVE_CLIPMETHOD from the FEAT_EVAL feature, since the option currently isn't compiled into tiny however I'm unsure about the cost of.)

dezza · 2026-08-01T11:24:27Z

thanks for working on this and thanks for careful thinking of exfiltration attacks.

Thanks sincerely for your always valued input @chrisbra and greatly appreciated continued effort in maintaining and handling everything (also the smaller side-projects and aspects which I can only imagine are larger than most think !)

Assuming enabling osc52 handling does not add much code for vim tiny, wouldn't it be much more useful to always enable this for tiny builds

I think we should instead make use of :set clipmethod even in tiny mode, so that users can selectively enable and disable the feature as they need it.

Try grep -R FEAT_CLIPBOARD its basically a very large chunk of what makes FEAT_NORMAL+.

instead of giving distributions the choice to disable it for their own tiny vim?

Its my wish and intention, that they look positively on this and embrace it - also why I am hesistant to rush it, but lets imagine for a moment, that this lands first as somewhat of a sleeper-feature (dormant, word of mouth, builds hype), matures and gets feedback and we listen to the major, common distro concerns.

Would they opt for just "patching it out" ? That would be a loss of trust. This why I've postponed this so many times and kept pondering about the best approach.

Honestly, I still believe writing openssh mailing list and hoping(🦜) for a positive and caring response would yield best results long-term, even if it initially seems unlikely.

It would remove the hindrance of distributions flat out rejecting it, because they are afraid of being called out, or compared, (or whatever).

With approval and access-controls in .ssh/config from openssh it would be much more commonly accepted and less feared.

On another point, how well is OSC52 actually supported by terminals nowadays? I read that writing to the clipboard is even more widely supported than reading the clipboard by terminals (for the same security concerns)? Is that true?

And finally, I am not so sure the $VIMOSC52 is a good choice.

Let me clarify:

Env var is not to promote usage of env vars as config
Promotes easy enabling without prior muscle-memory or knowhow of arguments.

Argument:
I think it might be underestimated by us, how many actually never configure vim, but use it as like a "fixed/maintained" vi on some server somewhere. This is the reason why I thought the env var makes it more accessible, easy to use and requires no initial memory or concern regarding configuring. I think, if a fellow sysadmin showed this trick, it would be a talking point, something worth sharing.

... lets investigate how many envvars are actually read right now besides the usual suspects DISPLAY,PATH,LINES,LC_*,XDG_* which are merely state/userenv.

netbeans.c is by far the largest user of envvars.

os_win32.c has a few.

A quick sweep follows of support (not verified 100%, take with grain of salt - just did a quick search and tried to find sources):

Terminal support

Read+write support:

Xterm - default: off
Alacritty - default: write
Ghostty - default: write +access_dialog
Foot - default: off (https://codeberg.org/dnkl/foot/src/branch/master/config.c#L1232-L1239)
Kitty - defaults: write +access_dialog
mintty - defaults: unknown
iTerm2 - default: off +access_dialog (https://iterm2.com/3.4/documentation-escape-codes.html)
(seems like iTerm have changed to the less standard OSC 1337 in 3.5 (https://iterm2.com/3.5/documentation-escape-codes.html) *sigh*

Write only support (defaults not checked):

tmux
Windows Terminal
Konsole
hterm (ChromeOS Secure Shell)
st
WezTerm
Contour
Rio

Stumbled upon a good writeup with considerations here: https://miliucci.org/post/linux-terminals-osc-52-escape/ the best part argument;
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).

tl;dr conclusion of article:
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.

dezza added 3 commits July 26, 2026 07:13

refactor(base64): detach from vimscript

18a4859

Make base64 functions and args independent from vimscript and its blob_T type.

configure(osc52): yes,no,only for tiny and regular

c991194

dezza changed the title ~~Feat osc52~~ feat(osc52) clipboard Jul 31, 2026

64-bitman reviewed Jul 31, 2026

View reviewed changes

Navigation Menu

Uh oh!

Uh oh!

feat(osc52) clipboard - #20896

feat(osc52) clipboard#20896
dezza wants to merge 3 commits into
vim:masterfrom
dezza:feat-osc52

dezza commented Jul 31, 2026 •

edited

Loading

Uh oh!

64-bitman Jul 31, 2026 •

edited

Loading

Uh oh!

dezza Jul 31, 2026

Uh oh!

64-bitman Jul 31, 2026

Uh oh!

dezza Jul 31, 2026 •

edited

Loading

Uh oh!

64-bitman commented Jul 31, 2026

Uh oh!

dezza commented Jul 31, 2026

Uh oh!

chrisbra commented Aug 1, 2026

Uh oh!

dezza commented Aug 1, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

dezza commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Configure, Feature

Environment variable

Why env var?

Integration with clipboard.c on regular build

Doc

Detection

Additional notes

Timeouts, performance

Security

Uh oh!

64-bitman Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dezza Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

64-bitman Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

dezza Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

64-bitman commented Jul 31, 2026

Uh oh!

dezza commented Jul 31, 2026

Uh oh!

chrisbra commented Aug 1, 2026

Uh oh!

dezza commented Aug 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Terminal support

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dezza commented Jul 31, 2026 •

edited

Loading

Integration with `clipboard.c` on regular build

64-bitman Jul 31, 2026 •

edited

Loading

dezza Jul 31, 2026 •

edited

Loading

dezza commented Aug 1, 2026 •

edited

Loading