alacritty: Copying text from Alacritty doesn't work intermittently

I find myself not being able to copy text some of the time from inside Alacritty.

I have the following keybindings in ~/.config/alacritty/alacritty.yml:

  - { key: Key3, mods: Alt, chars: "#" }
  - { key: C, mods: Control|Shift, action: Copy }
  - { key: V, mods: Control|Shift, action: Paste }

When I press ctrl-shift-C:

  • Some of the time nothing at all is copied.
  • Some of the time something garbled is copied (e.g. some text that’s on screen somewhere but not what I selected, some text that’s only part of my selection, some text that crosses the boundary of my selection)
  • Some of the time my selection is copied correctly.

Most of the time I’m inside a tmux session when I use Alacritty, but I’ve reproduced this just fine outside of tmux, so I don’t think it’s strictly being caused by tmux.

My Alacritty config file sets $TERM to xterm-256color, and my tmux config sets:

set  -g default-terminal "tmux-256color"
set -ga terminal-overrides ",xterm-256color:RGB"

As a result, inside tmux, my $TERM is set to tmux-256color, and outside it’s set to xterm-256color.

My tmux config also sets:

set -g mouse on


OS: Linux (NixOS) Version: alacritty 0.8.0 Linux/BSD: X11, none+bspwm with picom compositor


Keyboard and bindings: alacritty --print-events: alacritty-event-log.txt

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 1
  • Comments: 21 (7 by maintainers)

Most upvoted comments

I faced something similar. Setup:

  • Arch Linux
  • sway --version --> sway version 1.7
  • alacritty --version --> alacritty 0.10.1 ()
  • alacritty set in “daemon” mode
  • new windows are opened with Mod+Enter set $term alacritty msg create-window --working-directory /home/vrein || alacritty

The problem:

  • after a while working in such server/client mode - the copy/paste functionality becomes laggy

How it feels:

  • [1] in the alacritty window I copied some text
  • [2] in the same window I pressed Shift+Ctrl+V the thing what got pasted - is the text that was copied before the step 1
  • [3] in the same window I pressed Shift+Ctrl+V – once more now the text I got - is what was copied on step 1

In general, it pastes once the buffer that was before current copy action.


I can confirm that this happens on Windows 10 too. Using powershell, gitbash, wsl, bash, sh, zsh, omzsh, and lastly when I’m ssh’ed from gitbash to bash on CentOS 7 with and without tmux locally and remotely.

I did notice that it happens more often when text wraps. Maybe that is what is causing it.

The other times it has happened is when the command nearly reaches the edge of the window, or after resizing the window.

I’ve been using it constantly for about a year in my development process, and it gets very frustrating, so I’ve stopped copying and pasting from it. Pasting to it seems to work great.

I can reproduce that newlines are added when commands are wrapped when copying from Alacritty every time. I just can’t reproduce the garbled text every time.

I can confirm same scenario is happening.

System: MacOS tmux: 3.2a alacritty: 0.9.0

Scenario: COPY from alacrity into outside editor. (1) Copy from outside editor and Paste into alacritty. (2) The output is a the content from (1) alacritty copy. Retry the same scenario, the issue goes away.

Very intermittent…

Yeah, sounds like two different issues. Especially if you can reliably reproduce it maybe open a separate issue @Warepire, but if it’s just an “every once in a while” thing in vi mode that suggests the issue might not necessarily be with Alacritty.

All right, I will see if I can figure out a semi-reliable reproducer, and then file a separate issue.

I’ve been getting similar effects on Linux, also intermittently. When it happens it sometimes copies a few chars, sometimes one or more lines, is consistent for the window after it happens, never seen it recover. Usually works fine in a new window. Copying with mouse always works 100%.

I don’t use tmux at all.

Alacritty version: HEAD commit as of writing (

OS: Arch Linux, kernel 5.13.12-arch1

Shell: zsh Possibly more common to happen while using vim or bat (, and after.