What causes "tmux load-buffer -w exited with {}" in Hmbown/CodeWhale?

Verify the server and version in the failing environment: tmux -V (needs >= 3.2) and tmux list-sessions.

tmux load-buffer -w exited with {}

Error message

tmux load-buffer -w exited with {}

What it means

The tmux clipboard path ran 'tmux load-buffer -w -' and it exited nonzero with empty stderr, so only the exit status is reported. Empty stderr typically means tmux could not even report a reason: lost connection to the server, stale TMUX environment variables pointing at a dead socket, or a tmux too old to support '-w' (the wait/wayland-related flag needs tmux >= 3.2).

Source

Thrown at crates/tui/src/tui/clipboard.rs:645

    let write_result = child
        .stdin
        .take()
        .context("open tmux clipboard input")
        .and_then(|mut stdin| {
            stdin
                .write_all(text.as_bytes())
                .context("write tmux clipboard input")
        });
    let output = child
        .wait_with_output()
        .context("wait for tmux load-buffer -w")?;
    write_result?;
    if !output.status.success() {
        let detail = String::from_utf8_lossy(&output.stderr);
        let detail = detail.trim();
        if detail.is_empty() {
            bail!("tmux load-buffer -w exited with {}", output.status);
        }
        bail!(
            "tmux load-buffer -w exited with {}: {detail}",
            output.status
        );
    }
    Ok(())
}

#[cfg(not(test))]
fn write_text_with_osc52(text: &str) -> Result<()> {
    let mut stdout = io::stdout();
    if !stdout.is_terminal() {
        bail!("OSC 52 clipboard fallback requires a terminal");
    }

    let sequence = osc52_sequence(text)?;
    stdout

View on GitHub (pinned to 0c42157ee5)

Solutions

Verify the server and version in the failing environment: tmux -V (needs >= 3.2) and tmux list-sessions.
Restart or reattach to a live tmux session so $TMUX points at a reachable socket, then retry the copy.
On tmux < 3.2, upgrade tmux, or use a system clipboard utility so the tmux path is not exercised.

Defensive patterns

Strategy: fallback

Validate before calling

fn tmux_load_buffer_supported() -> bool {
    std::env::var_os("TMUX").is_some()
        && Command::new("tmux").arg("-V").output()
            .map(|o| String::from_utf8_lossy(&o.stdout).trim().split('.').nth(1).and_then(|mi| mi.parse::<u32>().ok()).map(|mi| mi >= 2).unwrap_or(false))
            .unwrap_or(false)
}

Try / catch

match write_text_with_tmux(text) {
    Err(e) if e.to_string().contains("tmux load-buffer -w exited") => {
        write_text_with_osc52(text) // server gone: use direct OSC 52
    }
    other => other,
}

Prevention

Require tmux >= 3.2 in environments that rely on load-buffer -w.
Unset stale TMUX/TMUX_PANE when detaching, or restart the server before copying.
Check tmux -V during setup and warn early rather than failing at copy time.

When it happens

Trigger: Copy while the tmux server is being killed or restarted; a stale $TMUX/$TMUX_PANE inherited from a detached session; tmux older than 3.2 where load-buffer rejects -w silently.

Common situations: Long-lived shells reusing a tmux env after 'tmux kill-server'; distros shipping tmux 3.0/3.1; nesting terminal multiplexers; scripts that inherit tmux variables without a live server.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/c29ae73c88d08450. Report an issue: GitHub.