Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clipboard size limit #3937

wincent opened this issue Aug 16, 2021 · 8 comments

Clipboard size limit #3937

wincent opened this issue Aug 16, 2021 · 8 comments


Copy link

wincent commented Aug 16, 2021

Describe the bug

Stuff copied to the clipboard via kitty +kitten clipboard or an explicit OSC 52 escape sequence created with printf fails silently above a certain size.

To Reproduce
Steps to reproduce the behavior:

Use seq to generate a large chunk of output to see where copies start failing:

  1. seq 1 914979 | kitty +kitten clipboard and inspect clipboard — sequence is there.
  2. seq 1 914980 | kitty +kitten clipboard and inspect clipboard — copy failed silently.
  3. seq 1 10000000 | pbcopy (ie. pipe to macOS clipboard tool) and inspect clipboard — even very large sequence is there.

Alternative, in Bash:

seq 1 914979 | printf "\e]52;c;%s\a" "$(cat - | openssl base64 -A)" # sequence gets copied
seq 1 914980 | printf "\e]52;c;%s\a" "$(cat - | openssl base64 -A)" # sequence does not get copied

Environment details

kitty 0.22.2 created by Kovid Goyal
Darwin gregorys-mbp 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64
ProductName:	macOS ProductVersion:	11.4 BuildVersion:	20F71
Loaded config files:

Config options different from defaults:
active_tab_font_style     (False, False)
active_tab_title_template  « {fmt.bold}{title}{fmt.nobold} » 
disable_ligatures         2
enable_audio_bell         False
font_family               Source Code Pro
font_size                 12.0
hide_window_decorations   1
inactive_tab_font_style   (False, True)
tab_bar_edge              1
tab_bar_style             separator
tab_separator             │
tab_title_template           {title}   
Added mouse actions:
	 cmd+b1 repeat ungrabbed KeyAction('mouse_click_url')
	 cmd+b1 repeat grabbed KeyAction('mouse_click_url')
Added shortcuts:
	ctrl+i KeyAction('send_text', ('application', b'H'))
	active_tab_background     #40383a   
	active_tab_foreground     #ffffff   
	inactive_tab_background   #1e1a1a   
	inactive_tab_foreground   #b5b5b4   
	tab_bar_background        #1e1a1a   
@wincent wincent added the bug label Aug 16, 2021
Copy link

There is an 8MB limit. Otherwise random programs running on remote
computers could DOS your local machine.

Copy link

wincent commented Aug 16, 2021

Doesn't 8 MB strike you as a little bit small? I'm typing this on a laptop with 2,000x that amount of physical RAM.

And they're not really "random" programs though, are they? They are programs that I chose to run, presumably because I trust them. Consider programs on the local machine too: they also could allocate arbitrary amounts of memory and "DOS" my machine, but I chose to run them.

Copy link

kovidgoyal commented Aug 16, 2021 via email

Copy link

wincent commented Aug 16, 2021

On a more serious note, what limit would you suggest?


🤷 — 10x the current limit?

Copy link

What is your usecase for copying 80MB of text via the clipboard? Downloading logs?

Copy link

wincent commented Aug 16, 2021

It could be logs, the output of a program, a debugging session in a REPL etc... I regularly want to capture a large amount of text from the terminal for sharing (for example, I might paste it into a private Gist). And this isn't on "random" machines. It's on machines that I regularly do development work on; if the systems are compromised, then the ability to inflate my local clipboard's memory footprint are the least of my concerns.

I just plucked the 10x figure out of the air because any number I say is going to be abritrary, but what I don't want is thinking that I've captured all the information when I actually haven't because the limit is applied silently. For example:

  1. Imagine I copy a large hunk of output, but less then 8 MB, and stick it in a Gist.
  2. I continue debugging, and copy a larger hunk, this time just more than 8 MB, and paste into a Gist.

In this scenario, I think I've captured two distinct sets of data, but I've actually captured the first one twice (because the second one never overwrote the previous clipboard contents), and because we're talking about logs which might look the same at first glance, I might not notice the information loss. And then I disconnect from the server, and the information is gone...

Now, I know I could redirect this kind of thing to a file (if I have the presence of mind to do that before running the command that generated the output), and then scp it somewhere else. But the simplicity of just being able to copy/paste is pretty awesome if you can rely on it.

Copy link

Well, I am willing to make an option for it, so you can set your own

Copy link

wincent commented Aug 16, 2021

Nice. Thanks @kovidgoyal!

wincent added a commit to wincent/wincent that referenced this issue Jul 25, 2022
As noted here:


I still don't have a good story for making Clipper do its thing both
locally (when I am sitting in front of my Linux box) and remotely (when
I am SSH'd into it from my laptop). As that issue describes, you _can_
use the OSC 52 support in kitty to get stuff into the clipboard
transparently, but, as explained here:


it has a hard cap on the size that you can copy this way, which makes me
hesitant to fully rely on it.

You can customize the limit with `clipboard_max_size`, but the fact that
there is a limit at all leads me to analysis paralysis... how to set
an arbitrary quantity like that? And even if I do get everything working
with kitty, I'm only using that on my personal machines, not my work
machine, so if I ever need to SSH in from my work machine to the Linux
box to do something (eg. grab some changes to my dotfiles or something)
I'll be left with inconsistent support.

I've gone back and forth on this in the past, see:

    commit bf75f40
    Date:   Sun Aug 15 10:57:49 2021 +0200

        refactor(dotfiles): [demo] teach `clip` to use OSC 52 escape sequence

    commit ef94ece
    Date:   Sun Aug 15 11:02:57 2021 +0200

        chore: revert "refactor(dotfiles): [demo] teach `clip` to use OSC 52 escape sequence"

    commit c85890b
    Date:   Sun Aug 15 11:17:03 2021 +0200

        refactor(dotfiles): switch back to using OSC 52 for `clip` when in Kitty
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants