Hmbown/CodeWhale · warning

PRIMARY selection unavailable

Error message

PRIMARY selection unavailable

What it means

write_primary_text writes to the X11 PRIMARY selection (middle-click paste) through the clipboard transport. It refuses when any precondition fails: primary selection unsupported, native terminal reads not permitted, empty text, or text exceeding PRIMARY_MAX_BYTES — surfacing a single generic bail.

Solutions

1. Check supports: only call when the platform/terminal advertises PRIMARY selection (uses_primary_selection())
2. Trim or truncate the text under PRIMARY_MAX_BYTES before writing
3. Ensure the terminal context permits native reads (not SSH host clipboard, restricted mode)
4. Treat the error as 'primary not available' and fall back to the regular clipboard or do nothing

Example fix

// before
clipboard.write_primary_text(selected)?;
// after
if clipboard.uses_primary_selection() && !selected.is_empty() && selected.len() <= PRIMARY_MAX_BYTES {
    let _ = clipboard.write_primary_text(selected);
}

if !clipboard.uses_primary_selection() || text.is_empty() || text.len() > PRIMARY_MAX_BYTES { /* skip or fallback */ }

match clipboard.write_primary_text(text) { Err(_) => { /* PRIMARY unavailable: fall back to clipboard or ignore */ }, Ok(()) => {} }

When it happens

Trigger: Calling write_primary_text when uses_primary_selection() is false (no X11/PRIMARY support, e.g. Wayland-only or Windows/macOS), terminal_context.permits_native_read() is false (restricted terminal), text is empty, or text longer than PRIMARY_MAX_BYTES.

Common situations: Selecting text in a terminal over SSH or in a sandbox that blocks native reads; running on a platform without PRIMARY selection; selecting an enormous output region past the byte cap and trying to publish it as PRIMARY.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• clipboard read failed
• PRIMARY selection busy or unavailable
• another terminal clipboard write is still queued
• cannot discard a loaded Runtime thread
• Check for an available update first.

AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/02e71d560cf059c0. Report an issue: GitHub.

Appendix: source

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

        #[cfg(test)]
        {
            self.primary_enabled
        }
        #[cfg(not(test))]
        {
            cfg!(all(target_os = "linux", not(target_env = "ohos")))
        }
    }

    /// Automatic selection never writes CLIPBOARD or sends OSC 52. A remote
    /// terminal without a forwarded display owns its own selection and paste.
    pub(crate) fn write_primary_text(&mut self, text: &str) -> Result<()> {
        if !self.uses_primary_selection()
            || !self.terminal_context.permits_native_read()
            || text.is_empty()
            || text.len() > PRIMARY_MAX_BYTES
        {
            bail!("PRIMARY selection unavailable");
        }
        #[cfg(test)]
        {
            if self.fail_text_writes {
                bail!("test PRIMARY unavailable");
            }
            self.primary_text = Some(text.to_string());
            Ok(())
        }
        #[cfg(all(target_os = "linux", not(target_env = "ohos"), not(test)))]
        {
            self.primary_selection()?.write(text)
        }
        #[cfg(all(not(test), not(all(target_os = "linux", not(target_env = "ohos")))))]
        {
            bail!("PRIMARY selection unavailable")
        }
    }

View on GitHub (pinned to 73e0f67d83)