neovide/neovide · error · std::io::Error

Unix Domain Sockets and Named Pipes are not supported on thi

Error message

Unix Domain Sockets and Named Pipes are not supported on this platform

What it means

connect_to_server supports connecting to nvim via Unix Domain Sockets (unix) or Windows Named Pipes (windows); on any other platform it returns an ErrorKind::Unsupported error because no transport is implemented. The error is a compile-time-configured capability guard, not a runtime failure of the connection itself.

Source

Thrown at src/bridge/session.rs:208

        } else {
            #[cfg(unix)]
            return Ok(Self::split(tokio::net::UnixStream::connect(address).await?));

            #[cfg(windows)]
            {
                // Fixup the address if the pipe on windows does not start with \\.\pipe\.
                let address = if address.starts_with("\\\\.\\pipe\\") {
                    address
                } else {
                    format!("\\\\.\\pipe\\{address}")
                };
                Ok(Self::split(
                    tokio::net::windows::named_pipe::ClientOptions::new().open(address)?,
                ))
            }

            #[cfg(not(any(unix, windows)))]
            Err(Error::new(
                ErrorKind::Unsupported,
                "Unix Domain Sockets and Named Pipes are not supported on this platform",
            ))
        }
    }

    #[cfg(not(target_os = "windows"))]
    fn forward_stdin(&self) -> Option<rustix::fd::OwnedFd> {
        use rustix::fs::{FileType, fstat};
        use std::os::fd::AsFd;

        // stdin should be forwarded only in embedded mode when stdio is piped or redirected
        match self {
            Self::Embedded(..) => {
                let stdin = std::io::stdin();
                let should_forward = fstat(stdin.as_fd())
                    .map(|stat| match FileType::from_raw_mode(stat.st_mode) {
                        FileType::RegularFile => true,

View on GitHub (pinned to ade2d9cda7)

Solutions

1. Build/run on a supported platform (Linux/macOS/BSD with UDS, or Windows with named pipes)
2. If targeting a new platform, implement the corresponding transport in connect_to_server behind its own cfg arm
3. Avoid compiling the bridge for unsupported targets, or cfg-gate out callers of connect_to_server for them

Example fix

// before
target_env = "wasm32"  // connect_to_server -> Unsupported
// after
// build for a supported target
cargo build --target x86_64-unknown-linux-gnu

#[cfg(any(unix, windows))]
fn supported() -> bool { true }
#[cfg(not(any(unix, windows)))]
fn supported() -> bool { false }

if !supported() {
    eprintln!("bridge requires unix (UDS) or windows (named pipes)");
    std::process::exit(1);
}

match connect_to_server(addr).await {
    Ok(session) => session,
    Err(e) if e.kind() == std::io::ErrorKind::Unsupported => {
        // fall back to TCP-based nvim connection (--listen) or abort gracefully
        connect_to_tcp_fallback(addr).await?
    }
    Err(e) => return Err(e.into()),
}

When it happens

Trigger: Calling connect_to_server on a platform where neither `unix` nor `windows` cfg attributes are active (e.g. wasm32 or other exotic targets), so the cfg(not(any(unix, windows))) arm is compiled in and hit.

Common situations: Cross-compiling or embedding Neovide's bridge code for wasm/unsupported OS targets; running test suites under an unusual target triple; porting the bridge to a new OS.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

AI-assisted analysis of neovide/neovide@ade2d9cda7 (2026-09-06). Data as JSON: /api/errors/ae79bdd370820e84. Report an issue: GitHub.