Is there a byte cap on OSC 52 clipboard writes?

No public spec cap, but both terminals and multiplexers apply practical limits in the kilobyte range — the right mental model is 'OSC 52 is a small-payload mechanism, not a binary-blob transport'. tmux truncates payloads beyond its internal buffer limit before forwarding to the outer terminal; iTerm2 caps OSC 52 input and gates the feature behind *Settings → General → Selection → Allow clipboard access* (off by default in fresh installs). vim's clipboard=osc52 and neovim's built-in OSC 52 provider both warn when they detect a too-large payload. Chunk large pastes, or reach for a dedicated transport (SCP, paste-by-URL) for files.

OSC 52 — System clipboard read/write

Set (or query) the host system clipboard via the terminal — works over SSH without X11 forwarding.

Byte forms

Every common string-literal form so you can paste-and-search either direction.

\\x1b[\x1b]52;c;BASE64\x07 (set clipboard 'c' to BASE64 decoded bytes)

\\033[\033]52;c;BASE64\007

\\e[\e]52;c;BASE64\a

ESC [ESC ] 52 ; SELECTION ; PAYLOAD BEL

hex1b 5d 35 32 3b ... 07

Description

Set the system clipboard from terminal output. The first parameter is the selection: c = CLIPBOARD, p = PRIMARY, s = secondary, q = 0..9 cut-buffers. The second parameter is base64-encoded bytes; a literal ? instead queries the current contents (and the terminal replies with \x1b]52;c;BASE64\x07). This is how tmux set -g set-clipboard on, vim (via clipboard=unnamedplus,osc52), neovim (vim.g.clipboard), and yazi --copy make yank work across SSH. Disabled by default in most terminals (security: a malicious log line can replace the user's clipboard); enable explicitly per terminal.

Spec citation: xterm-ctlseqs (OSC 52)

Examples

bash

printf '\033]52;c;%s\007' "$(printf 'hello' | base64)"

python

import sys, base64\npayload = base64.b64encode(b'hello').decode()\nsys.stdout.write(f'\x1b]52;c;{payload}\x07')

import "encoding/base64"\nfmt.Printf("\x1b]52;c;%s\x07", base64.StdEncoding.EncodeToString([]byte("hello")))

javascript

process.stdout.write('\x1b]52;c;' + Buffer.from('hello').toString('base64') + '\x07')

/* assumes base64_encode() helper */\nprintf("\x1b]52;c;%s\x07", base64_encode("hello", 5));

Used in

Real-world tools that emit this sequence — anchors the bytes to commands you've already used.

tmux`set -g set-clipboard on` — copy-mode selections write to OSC 52 so the host clipboard receives them through ssh
neovimthe built-in `osc52` provider lets `"+y` work over ssh without xclip on the remote
vim with vim-oscyank pluginadds `:OSCYank` so yanks travel through ssh / tmux to the host clipboard
kitty `kitten clipboard` and `kitty +kitten icat` helpers
lazygit — `y` to copy commit SHA via OSC 52 in supporting terminals

Frequently asked

Short answers to the questions developers actually search for this sequence.

Is there a byte cap on OSC 52 clipboard writes?: No public spec cap, but both terminals and multiplexers apply practical limits in the kilobyte range — the right mental model is 'OSC 52 is a small-payload mechanism, not a binary-blob transport'. tmux truncates payloads beyond its internal buffer limit before forwarding to the outer terminal; iTerm2 caps OSC 52 input and gates the feature behind *Settings → General → Selection → Allow clipboard access* (off by default in fresh installs). vim's clipboard=osc52 and neovim's built-in OSC 52 provider both warn when they detect a too-large payload. Chunk large pastes, or reach for a dedicated transport (SCP, paste-by-URL) for files.

Common typos / look-alikes

Wrong forms developers commonly paste from Stack Overflow that look right but aren't — with the canonical correction inline.

\x1b]52;c;Hello\x07 (raw text after the channel)\x1b]52;c;SGVsbG8=\x07 (base64-encoded payload)
OSC 52 mandates base64 (RFC 4648) for the payload — terminals reject any non-base64 character (anything outside A-Z, a-z, 0-9, +, /, =) and drop the whole sequence. The ;c; is the channel marker (c = clipboard, p = primary on X11); the bytes AFTER it must be base64. Most failures look like a silently-empty clipboard rather than a visible error.
\x1b]52;cp;SGVsbG8=\x07 (treating channel as 2-char abbreviation)\x1b]52;c;SGVsbG8=\x07 (channel is one of c, p, q, s, 0-7)
The channel field is a single character (or a digit), not a free-form name. Valid channels: c = CLIPBOARD, p = PRIMARY, q = secondary, s = select, 0–7 = cut-buffers 0–7. Combinations like cp or cs are ignored as unknown channel (no write). A few terminals accept the empty channel as a default (\x1b]52;;<base64>\x07 writes to whatever the default destination is) — relying on this is non-portable.
\x1b]52;c;<long-base64>\x07 over plain SSH (no tmux passthrough)enable set -g allow-passthrough on in ~/.tmux.conf; ssh client must forward \e byte (no LANG=C mangling)
OSC 52 is the canonical answer to 'I'm SSH'd into a remote box, how do I get its output onto my local clipboard?' — but it fails by default in tmux. tmux strips OSC 52 unless allow-passthrough on is set; over chained SSH the inner shell's escape can also be eaten by an intermediate screen / tmux / mosh layer. Test bottom-up: bare ssh → confirm clipboard works → add tmux → confirm again. A tmux: set-clipboard on flag controls the *receiving* side; allow-passthrough controls forwarding from inner programs.

Terminal support

xterm: yes
Linux console (fbcon): no
macOS Terminal.app: no
iTerm2: yes
Windows Terminal: partial
cmd.exe / ConPTY: no
kitty: yes
alacritty: yes
WezTerm: yes
Ghostty: yes
GNOME Terminal: partial
Konsole: yes
tmux: partial
GNU screen: no

xterm	Linux console (fbcon)	macOS Terminal.app	iTerm2	Windows Terminal	cmd.exe / ConPTY	kitty	alacritty	WezTerm	Ghostty	GNOME Terminal	Konsole	tmux	GNU screen
yes	no	no	yes	partial	no	yes	yes	yes	yes	partial	yes	partial	no