zed-industries/zed · critical

X11 connection: File descriptor passing failed

Error message

X11 connection: File descriptor passing failed

What it means

handle_connection_error maps XCB ConnectionErrors; most become anyhow errors, but FdPassingFailed is treated as unrecoverable and panics. Passing file descriptors over the X connection (SCM_RIGHTS on a Unix socket) is required for functionality Zed depends on (e.g. shared-memory buffers), so a connection that cannot pass fds is unusable.

Source

Thrown at crates/gpui_linux/src/linux/x11/window.rs:439

    hints.urgent = urgent;
    check_reply(
        || "X11 ChangeProperty for WM_HINTS urgency failed.",
        hints.set(xcb, x_window),
    )
    .log_err();
    xcb_flush(xcb);
}

/// Convert X11 connection errors to `anyhow::Error` and panic for unrecoverable errors.
pub(crate) fn handle_connection_error(err: ConnectionError) -> anyhow::Error {
    match err {
        ConnectionError::UnknownError => anyhow!("X11 connection: Unknown error"),
        ConnectionError::UnsupportedExtension => anyhow!("X11 connection: Unsupported extension"),
        ConnectionError::MaximumRequestLengthExceeded => {
            anyhow!("X11 connection: Maximum request length exceeded")
        }
        ConnectionError::FdPassingFailed => {
            panic!("X11 connection: File descriptor passing failed")
        }
        ConnectionError::ParseError(parse_error) => {
            anyhow!(parse_error).context("Parse error in X11 response")
        }
        ConnectionError::InsufficientMemory => panic!("X11 connection: Insufficient memory"),
        ConnectionError::IoError(err) => anyhow!(err).context("X11 connection: IOError"),
        _ => anyhow!(err),
    }
}

impl X11WindowState {
    pub fn new(
        handle: AnyWindowHandle,
        client: X11ClientStatePtr,
        executor: ForegroundExecutor,
        gpu_context: gpui_wgpu::GpuContext,
        compositor_gpu: Option<CompositorGpuHint>,
        params: WindowParams,

View on GitHub (pinned to 9d272b0363)

Solutions

1. Use a local Unix-socket X connection: set DISPLAY=:0 (or unix:0) instead of hostname:0
2. For remote usage, prefer a local session or a protocol that doesn't depend on X fd passing (Wayland remote, VNC-native)
3. Check that container/seccomp/sandbox policy permits SCM_RIGHTS on the X socket

Example fix

# before
export DISPLAY=192.168.1.10:0   # TCP -> fd passing unavailable -> panic

# after
export DISPLAY=:0                # local unix socket

# shell: ensure DISPLAY targets a local unix socket, not TCP
case "${DISPLAY:-}" in
  :[0-9]*|unix:[0-9]*) ;;        # local: ok
  *) echo "DISPLAY=${DISPLAY:-} is remote/TCP; fd passing unavailable" ;;
esac

When it happens

Trigger: The X connection does not support file descriptor passing — typically X servers reached over TCP (DISPLAY=hostname:0) or through proxies/sandboxing that strip SCM_RIGHTS ancillary data (xrdp, some VNC setups, container/seccomp restrictions).

Common situations: Remote X over the network instead of a local socket; xrdp sessions; DISPLAY pointing at a remote host; hardened sandboxes blocking ancillary messages on the socket.

Related errors

• X11 connection: Insufficient memory
• `{}` must be a positive normal number or `randr`. Got `{}`
• `{}` must be a positive number or `randr`. Got `{}`
• blocking sender returned without value
• wl_seat below required version: {} < {}

AI-assisted analysis of zed-industries/zed@9d272b0363 (2026-08-20). Data as JSON: /api/errors/6986ee40a4ccfe46. Report an issue: GitHub.