What causes "{program} exited with {status}" in Hmbown/CodeWhale?

Confirm wl-copy works by hand in the same environment: echo hi | wl-copy && wl-paste.

{program} exited with {status}

Error message

{program} exited with {status}

What it means

wl-copy (Wayland clipboard writer) spawned and received the text on stdin, but the process exited nonzero, so the write is reported failed. The text is piped and stdin closed before waiting, so a nonzero exit usually means wl-copy could not reach the Wayland clipboard rather than a short write (those produce the 'Failed to write to ...' error instead).

Source

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

#[cfg(all(target_os = "linux", not(target_env = "ohos"), not(test)))]
fn write_text_with_wlcopy_using_argv(program: &str, text: &str) -> Result<()> {
    let mut child = Command::new(program)
        .stdin(Stdio::piped())
        .stdout(Stdio::null())
        .stderr(Stdio::null())
        .spawn()
        .map_err(|e| anyhow::anyhow!("Failed to run {program}: {e}"))?;
    if let Some(mut stdin) = child.stdin.take() {
        stdin
            .write_all(text.as_bytes())
            .map_err(|e| anyhow::anyhow!("Failed to write to {program}: {e}"))?;
    }
    // stdin is dropped here, closing the pipe so wl-copy flushes.
    let status = child
        .wait()
        .map_err(|e| anyhow::anyhow!("Failed to wait on {program}: {e}"))?;
    if !status.success() {
        bail!("{program} exited with {status}");
    }
    Ok(())
}

#[cfg(not(test))]
fn write_text_to_terminal_client(text: &str, in_tmux: bool) -> Result<()> {
    if in_tmux {
        return write_text_with_tmux(text);
    }
    write_text_with_osc52(text)
}

#[cfg(not(test))]
fn write_text_with_tmux(text: &str) -> Result<()> {
    write_text_with_tmux_using_argv("tmux", &[], text)
}

/// Ask tmux to set both its paste buffer and the attached client's clipboard.

View on GitHub (pinned to 0c42157ee5)

Solutions

Confirm wl-copy works by hand in the same environment: echo hi | wl-copy && wl-paste.
Export WAYLAND_DISPLAY and XDG_RUNTIME_DIR into Codewhale's environment, or run inside tmux so the load-buffer path is used.
On X11, install xclip/xsel so wl-copy is not selected as the write backend.

Defensive patterns

Strategy: fallback

Validate before calling

fn wl_copy_likely_works() -> bool {
    std::env::var_os("WAYLAND_DISPLAY").is_some()
        && std::env::var_os("XDG_RUNTIME_DIR").is_some()
}

Try / catch

match write_text_with_wlcopy_using_argv("wl-copy", text) {
    Ok(()) => Ok(()),
    Err(_) => write_text_with_osc52(text), // fall back to OSC 52 / tmux
}

Prevention

Verify the backend by hand: echo hi | wl-copy && wl-paste in the same shell.
Keep a second clipboard path (tmux or OSC 52) enabled so failures degrade instead of erroring.
Remember empty text makes some wl-clipboard versions exit nonzero; skip empty writes.

When it happens

Trigger: wl-copy present but no accessible compositor: WAYLAND_DISPLAY unset/stale, running over plain SSH, or the clipboard seat disappeared; some wl-clipboard versions also exit nonzero when stdin content is empty.

Common situations: Remote SSH into a desktop session without forwarding WAYLAND_DISPLAY; environment where wl-clipboard is installed on an X11 machine; tests invoking the argv path outside a compositor.

Related errors

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