Copy functionality doesn't work on wezterm

[bash-bunny]

I've been trying to use the copy functionality, like selecting part of a request and use y, or use space + Y to copy the body, on the history, or in the repeater, but nothing seems to copy to the clipboard.

I'm using wezterm with nushell.

I've tested also with alacritty and bash, and it seems to work perfectly, I've been able to copy the body from a history request and from the repeater.

Awesome functionality, it makes me go faster to move things around, I could use alacritty in the meantime, but if you find a solution for wezterm, let me know.

[hahwul]

Hi @bash-bunny
Thank you for your report. I'm currently looking into the cause.
It's not a direct bug, but there’s a related issue that we're already working on fixing

I'll keep track of the progress and update you as we go. Thanks!

[hahwul]

Test

• macOS + gori v0.2.0 + wezterm stable·nightly -> OK
• macOS + gori main branch + wezterm stable·nightly -> OK
• Linux (debian) + gori v0.2.0 + wezterm stable·nightly -> OK
• Linux (debian) + gori main + wezterm stable·nightly -> OK
• Linux (arch) + gori v0.2.0 + wezterm stable·nightly -> OK
• Linux (arch) + gori main + wezterm stable·nightly -> OK

Hmm....

[hahwul]

Hi @bash-bunny

I tried reproducing it on macOS and Linux, with wezterm stable and nightly, with and without a config file. Copy worked in every one, so I need a bit more from your side

• OS, and X11 / Wayland / macOS?
• Do you use a clipboard manager?
• wezterm --version
• Do you use wezterm connect, wezterm ssh, or a mux domain?
• Outside gori and nushell, does this reach your clipboard?
  bash -c 'printf "\033]52;c;%s\a" "$(printf gori-test | base64)"'

That last one tells us whether gori is involved at all. Thanks!

[bash-bunny]

Hello @hahwul

Thank you for all the tests, I'll try to answer each of the questions:

• OS: NixOS 26.05 with X11 on xmonad
• Clipboard manager: not right now, I use xclip or xsel to copy things from and to the terminal
• Wezterm version: wezterm 0-unstable-2026-03-31
• I don't usually spawn wezterm connect, I use only wezterm to launch a new terminal
• I've tested that line inside wezterm with bash and with nushell and in both cases it copy to the clipboard this: gori-test

Also, maybe this helps, I've tried a wezterm without my configuration, and the copy from the history works from bash and from nushell, so it's 99% my configuration.

I'm reviewing it, the only "weird" thing I've got is this:

-- Domains for multiplexing
config.unix_domains = {
  {
    name = 'unix',
    -- local_echo_threshold_ms = 10,
  },
}

The rest is related to scrollback, the theme, the tabs, and how it looks in general, also the keybindings for spliting the terminal.

[hahwul]

Hi @bash-bunny
Thanks! This will be really helpful. I can't reproduce it right away at the moment,
so I’ll try setting up the environment based on the information you shared and work on solving the issue!

Thanks for your help :)

[hahwul]

notes

(Investigation notes left by a Claude agent — cc @hahwul)

Reproduced this in a container built to match the reporter's stack. It is not a gori bug. wezterm silently discards OSC 52 clipboard writes from every window except its oldest one, and gori's copy is one of them.

The rule

Three windows of a single wezterm-gui process, alive in the same session, each addressed individually and focused with a real pointer click:

window	how it was created	OSC 52 delivered
1st	wezterm start	6/6
2nd	ctrl+shift+n (SpawnWindow)	0/5
3rd	a second wezterm start (reuses the process)	0/6

Identical on wezterm 0-unstable-2026-03-31 (the reporter's exact version, pinned via nixpkgs rev 869d1be3) and 0-unstable-2026-07-16.

And in the same pane of window 2, a raw printf and gori's History y back to back — 3/3 runs identical:

w1 printf (before)        DELIVERED        pane=0 tty=/dev/pts/0
w2 printf (before gori)   *** DROPPED ***  pane=1 tty=/dev/pts/1
gori 'y' in that w2 pane  *** DROPPED ***
w1 printf (after)         DELIVERED        pane=0 tty=/dev/pts/0

The screenshot of that run shows gori's status bar reading copied GET /small to clipboard (134b) while the X CLIPBOARD still holds the test sentinel. That is exactly what was reported: no error, nothing copied.

Mechanism

A sentinel xclip owner was parked on the CLIPBOARD selection before every copy, then checked for survival (with xsel -b -o as a second, independent reader):

	clipboard reads	sentinel owner
oldest window (delivered)	both readers return the marker	dead — wezterm took ownership
other window (dropped)	both readers return SENTINEL	alive — XSetSelectionOwner was never called

So the write dies before it reaches X. It is not "wezterm owns the selection but serves nothing".

Closing the oldest window heals the next one (2/2). The rule is currently-oldest, not first-ever — which is why the behaviour looks random, and why the wezterm#5917 commenter described it as "randomly stops until you kill all instances and restart".

Why "it's my config" was a red herring

The reporter's A/B (works without config, fails with it) is fully explained without the config being involved: the failing copy ran in their normal multi-window session, and the "wezterm without my configuration" check — and the working printf OSC 52 test — were single fresh windows. Confirmed by sweeping 37 config options on both wezterm versions: front_end (OpenGL/Software/WebGpu), term, kitty keyboard, CSI-u, NFC normalisation, scrollback, every mux/domain variant (default_domain, connect_automatically, default_gui_startup_args, wezterm connect unix), tiling_desktop_environments, mouse/input options. All pass in the oldest window; the second window fails with a bare wezterm.config_builder(). unix_domains — the one fragment quoted in this thread — is irrelevant.

Also ruled out: payload size (100 B → 400 KB all delivered intact), > /dev/tty vs stdout, wezterm version, and focus (the second window drops even while genuinely focused, xdotool getwindowfocus == that window).

gori's side is clean

Captured gori's raw byte stream off a bare pty first (deliberately not tmux — Clipboard.copy branches on $TMUX into a DCS wrap, a different code path). Small copies and a 381 KB response body:

• sequence contiguous ESC ] 52 ; c ; <base64> BEL, nothing spliced in — even at 87,380 base64 bytes, which cannot leave in a single write()
• payload pure base64, decodes, and decodes to valid UTF-8
• the 64 KB cap landed on a codepoint boundary (65,534 bytes of a multibyte body)

Minimal repro (no container needed)

In wezterm's first window:

printf '\033]52;c;%s\a' "$(printf from-window-1 | base64 -w0)"; xclip -o -selection clipboard

Then ctrl+shift+n for a second window, and in it:

printf '\033]52;c;%s\a' "$(printf from-window-2 | base64 -w0)"; xclip -o -selection clipboard

The second one leaves the clipboard untouched.

Workaround until upstream fixes it

Copy from wezterm's oldest window, or work in single-window sessions. Closing the oldest window promotes the next one.

Caveats on the environment

Container, not a real NixOS session: nixos/nix + nixpkgs on aarch64-linux, Xvfb + openbox standing in for X11 + xmonad, no dbus/xdg-desktop-portal. The reporter's wezterm version, shell (nushell) and gori v0.2.0 release binary are exact. Worth one confirmation on real hardware with the minimal repro above before opening anything upstream.

Related open wezterm issues, none of which name the window index — #5917 (blames the config file), #1790, #764.

One thing worth deciding on gori's side

OSC 52 has no acknowledgement, so a terminal that parses the sequence and drops it is undetectable — the toast will read "copied … to clipboard" either way. That is inherent to the current design (Clipboard.copy is OSC 52 only, on purpose: works over SSH, no platform dependency). Writing a native clipboard (xclip/wl-copy/pbcopy) alongside the OSC 52 when the session is local would cover this class. A design call, not a bug fix.

_{Method note: the test harness produced five separate false reproductions before this result held, each looking exactly like the reported bug (single-sample clipboard reads racing X ownership transfer, wezterm start -- <prog> being silently ignored under a mux default_domain, stale xdotool window ids, a stuck key chord, and a program that never launched). Every verdict above comes from interleaved repeated trials with an execution receipt recording $WEZTERM_PANE and tty, so "the command never ran" can never be scored as "the copy was dropped".}