Hmbown/CodeWhale · warning
{program} exited with {}
Error message
{program} exited with {} What it means
wl-paste (the Wayland clipboard reader, run with --no-newline --type text/plain) was launched successfully but exited with a nonzero status, so its stdout is discarded and the read fails. The status in the message distinguishes this from launch failures ('Failed to run ...'). The function is used on Linux (non-OHOS) builds and in tests via explicit argv.
Source
Thrown at crates/tui/src/tui/clipboard.rs:572
}
#[cfg(all(target_os = "linux", not(target_env = "ohos"), not(test)))]
fn read_text_with_wlpaste() -> Result<String> {
read_text_with_wlpaste_using_argv("wl-paste")
}
#[cfg(any(all(test, unix), all(target_os = "linux", not(target_env = "ohos"))))]
fn read_text_with_wlpaste_using_argv(program: &str) -> Result<String> {
let output = Command::new(program)
.arg("--no-newline")
.arg("--type")
.arg("text/plain")
.stdout(Stdio::piped())
.stderr(Stdio::null())
.output()
.map_err(|e| anyhow::anyhow!("Failed to run {program}: {e}"))?;
if !output.status.success() {
bail!("{program} exited with {}", output.status);
}
String::from_utf8(output.stdout).context("wl-paste returned non-UTF-8 text")
}
#[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.View on GitHub (pinned to 0c42157ee5)
Solutions
- Verify a Wayland session and export WAYLAND_DISPLAY (and XDG_RUNTIME_DIR) into the Codewhale process.
- If on X11, install xclip/xsel so the clipboard stack picks the matching backend instead of wl-paste.
- Update wl-clipboard if the exit comes from option incompatibility; run wl-paste --no-newline --type text/plain manually to reproduce.
Defensive patterns
Strategy: fallback
Validate before calling
fn wl_paste_likely_works() -> bool {
std::env::var_os("WAYLAND_DISPLAY").is_some()
&& std::env::var_os("XDG_RUNTIME_DIR").is_some()
} Try / catch
match read_text_with_wlpaste_using_argv("wl-paste") {
Ok(text) => Ok(text),
Err(_) => read_text_with_osc52_fallback(), // try the next backend
} Prevention
- Export WAYLAND_DISPLAY and XDG_RUNTIME_DIR into the app's environment on Wayland.
- On X11, install xclip/xsel so the wl-paste path is never chosen.
- Reproduce manually with wl-paste --no-newline --type text/plain before filing bugs.
When it happens
Trigger: wl-paste is installed but cannot reach a clipboard: no Wayland compositor (WAYLAND_DISPLAY unset or stale), no clipboard manager owns a selection, or the wl-clipboard version rejects the --type text/plain combination.
Common situations: SSH sessions into a Wayland desktop where WAYLAND_DISPLAY is not exported; X11-only sessions where wl-paste is installed as part of a distro bundle; wl-clipboard running with no compositor: it exits nonzero rather than returning empty.
Related errors
- {program} exited with {status}
- tmux load-buffer -w exited with {}
- tmux load-buffer -w exited with {}: {detail}
- selection is too large for OSC 52 clipboard fallback
- OSC 52 clipboard fallback requires a terminal
AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20).
Data as JSON: /api/errors/1f67294e320713e6.
Report an issue: GitHub.