I am having this issue for about 2 years now (since I started to use tmux in Summer 2018) and I have not found a solution to this problem. Any help is greatly appreciated!

The copy functionality of tmux is slow. Often times when I copy using mouse selection, and then I paste in the terminal it almost always pastes what I thought was in the clipboard previously, it never copied the current mouse over selection into the clipboard. I have to select and then wait for a bit (usually a second or so).

I am so used to the copy current mouse selection from linux, iTerm2 on macOS and they are blazingly fast, I never have to think about or wait for the selection to be copied.

This causes problems because sometimes my clipboard has sentences and when I mouse over let's say a dir path/filename/git commit hash, etc. and paste in the terminal thinking that a dir path/filename/git commit hash will be pasted, here comes a barrage of sentences.

I have tried a few ways to address this problem none of them to my satisfaction.

  1. I tried to print a message after the copy was done:

    bind -T copy-mode-vi Tab send -X copy-pipe "reattach-to-user-namespace pbcopy"\; display-message "copied to system clipboard"
  2. I saw the mistake I was doing with calling reattach-to-use-namespace every time on selection, so instead, I started tmux only once with this program:

    set-option -g default-command "reattach-to-user-namespace -l bash"
    bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe "pbcopy" \; display-message "copied to system clipboard"
  3. Later I switched to tmux-plugins/tmux-sensible which starts tmux with reattach-to-user-namespace.

  4. And now a few weeks back I disabled all the bind-key copy configuration and switched to tmux-plugins/tmux-yank. I prefer the tmux-yank configuration better than what I had. But the slowness or delay in copying still persists, I am often pasting the wrong information, thinking the mouse selection is copied into the system clipboard.

I also running updated software as much as possible, hoping to see some improvements. The issue is I do not where the problem is to debug further. Is the slowness in tmux or reattach-to-user-namespace or Alacritty or OS X.

I tried switching back to iTerm2 because this issue was getting annoying but after using Alacritty, iTerm2 is sluggish and slow, as I am streaming a lot logs in the terminal for debugging. And unfortunately Alacritty does not support multi-window mode or tabs at the moment.

Alacritty+tmux on macOS is the perfect solution at the moment for me, except for this once annoyance with the slowness in copy.

I am running:

I ran into this https://github.com/alacritty/copypasta, I want to give this a try and see if this improves the situation.

And just for writing this question, I pasted the wrong info many times and had to go back and wait for the copy to properly finish.

1 Answer 1


reattach-to-user-namespace should not be necessary anymore, you can try without it entirely.

There is little tmux could be doing to make copying a small amount of text take a couple of seconds so probably this is pbcopy.

If your terminal supports OSC 52 (iTerm2 does, I'm not certain about alacritty), you could use it instead of pbcopy - see https://github.com/tmux/tmux/wiki/Clipboard.

If you are not using OSC 52, make sure to turn set-clipboard off.

  • Hi @nicholas-marriott, thanks for your response! So alacritty does support OSC 52, github.com/alacritty/alacritty/blob/master/CHANGELOG.md#fixed-2. I have done the following to make sure nothing but the internal tmux copy to system clipboard is being executed: - uninstalled reattach-to-user-namespace - disabled tmux-sensible plugin (which turns on reattach-to-user-namespace for macOS) - set -s set-clipboard on - disable alacritty's save to clipboard option: alacritty.yml: ``` selection: save_to_clipboard: false ``` The copy is working fine from tmux on select.
    – krafts
    May 27, 2020 at 18:58
  • I am unable format the response correctly. I am testing the changes I made and will report back in a day or two.
    – krafts
    May 27, 2020 at 19:02
  • I have also disabled tmux-yank plugin and just relying on set-clipboard. Things are working so far.
    – krafts
    May 27, 2020 at 19:15
  • Okay so after much use, I have noticed that the issue is not with tmux being slow but my behavior on how I use the copy on selection. I am hardwired to how iterm2 does the copy, it copies as the selection happens. On tmux, the copy happens when the left mouse button is released with the binding, MouseDragEnd1Pane. I am so used to this behavior that I keep pasting the selecting ever before releasing the mouse and hence the old value of the clipboard keeps being pasted. Which mistakenly I thought was slowness in the tmux copy.
    – krafts
    Jun 2, 2020 at 18:02
  • I have found some documentation on the wiki about MouseDragEnd1Pane github.com/tmux/tmux/wiki/…. And an issue that discusses this behavior, github.com/tmux/tmux/issues/1804. I was unsuccessful in getting MouseDrag1Pane to bind to copy, it breaks the selection of text when scrolled back in the buffer. But over all I have more insight into what is happening! Thank you @nicholas-marriott!!
    – krafts
    Jun 2, 2020 at 18:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .