Clipboard (most times) not working between terminals
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
niri (niri 25.01)
WezTerm version
wezterm 0-unstable-2025-02-10
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
i cant copy a selected text in one window and paste it in another, except sometimes after waiting ~10 minutes. copy/pasting from/to other windows works. also tried on build from 3.1.2025 (i believe).
i am working on nixos with the unstable channel and home-manager.
To Reproduce
use the software mentioned above (it maybe occurs with any compositor, havent tested it).
Configuration
no clipboard-related config
Expected Behavior
copy-paste between windows working
Logs
Debug Overlay wezterm version: 0-unstable-2025-02-10 x86_64-unknown-linux-gnu Window Environment: Wayland Lua Version: Lua 5.4 OpenGL: Mesa Intel(R) UHD Graphics 620 (KBL GT2) 4.6 (Compatibility Profile) Mesa 24.3.4 Enter lua statements or expressions and hit Enter. Press ESC or CTRL-D to exit 16:24:25.546 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
Anything else?
No response
Since you edited the title, is it an issue only between terminals? (which ones?) Does it work with other windows?
it maybe occurs with any compositor, havent tested it
I don't know niri, would be interesting to check another one to rule out this as a niri issue?
Since you edited the title, is it an issue only between terminals? (which ones?)
only between wezterms, copying to/from alacritty and firefox works.
I don't know niri, would be interesting to check another one to rule out this as a niri issue?
tested on sway, there no problem, so probably something between wezterm and niri.
Here also copy in Niri broken. Unable to copy to other windows at all, incl. Wezterm windows. Each Wezterm window has kinda it's own clipboard. I copy to micro as a workaround -- from micro it copies okay. All paste works okay. On Sway no issue with copy. Arch Linux stable.
I'm also on niri and having issues pasting to WezTerm. Alacritty works without issue. Unclear why. Most recently I found that copying from Firefox and pasting into WezTerm wasn't working.
For me I can reproduce by attempting to copy the SSH path of a GitHub repository from the repository overview page (dropping down from the green button on the right hand side) and then trying to paste that into WezTerm.
I'm also on niri and my clipboard with wezterm is living own life. I also have the problem that I can't copy text from one window of wezterm to another. Alacritty works fine.
Also I can insert a text from any application to only first window of running wezterm. But with some manipulation I can insert the text to other windows of wezterm
- Copy any text (e.g. from browser).
- Open 1st
weztermwindow and paste it. All works. - Open 2nd window
weztermwithout closing the previous one. Paste does not work in this window. - Open
alacrittywindow. Paste text in this window. All works. - Return to the 2nd window of
weztermand paste will work without any manipulation with clipboard. - Open 3rd window
wezterm. Paste doesn't work. - Continue.....
let me know if my PR works to fix the clipboard issues. I've been using it for about 3 weeks with no issue, but I'd like to know if it solves the issue for others
Still a thing in wezterm 20251014-193657-64f2907c, it looks like the first (or current) wezterm window to be focused after a clipboard update is the one that can paste.
I also have a workaround for until the pr gets merged:
-- wezterm.lua
wezterm.on(
'window-focus-changed',
function(window, pane)
wezterm.run_child_process { 'sh', '-c', 'wl-paste -n | wl-copy' }
end
)
It literally just re-copies the current clipboard whenever you focus a window, which updates wezterm's clipboard state. Most clipboard history tools ignore duplicates, so it shouldn't clog up the history.
I laso have a workaround. Switching to alacritty :)
KWin developer here... I looked at the issue from the compositor side. It appears like wezterm expects the wl_data_device.selection event after every keyboard focus change.
Prior to 6.5, KWin used to send the selection event when switching between two surfaces even though they belong to the same client. Since 6.5, KWin adheres more to the wayland spec and this issue appeared.