denoland/deno · error

LAUFEY backend exited with status: {}

Error message

LAUFEY backend exited with status: {}

What it means

Thrown after the spawned LAUFEY backend process (the CEF-based webview host that `deno desktop` runs your app in) terminates with a non-zero exit status. The message includes the process status (exit code or signal). Everything before it — the runtime dylib path, LAUFEY_APP_ICON/NAME env, DENO_DESKTOP_HMR wiring — was set up; the failure is in the GUI backend process itself, not in your JS code.

Source

Thrown at cli/tools/desktop.rs:1496

      .kill_on_drop(true)
      .spawn()
      .with_context(|| {
        format!(
          "Failed to launch LAUFEY backend: {}",
          laufey_backend.display()
        )
      })?;
    child
      .wait()
      .await
      .context("Failed waiting for LAUFEY backend")?
  };

  // Keep the mux alive until the subprocess exits, then drop it.
  drop(mux_handle);

  if !status.success() {
    bail!("LAUFEY backend exited with status: {}", status);
  }
  Ok(())
}

/// Marker file written into every generated desktop app directory/bundle so a
/// later build can recognize its own previous output and clear it, while never
/// touching unrelated user data that happens to share the inferred app name.
const APP_DIR_MARKER: &str = ".deno-desktop-app";

/// Used for `deno desktop --hmr` when a framework runs its own HMR server.
/// The compiled app has nothing to serve in this case.
const NOOP_ENTRYPOINT: &str =
  "// @ts-nocheck\nawait new Promise<void>(() => {});\n";

/// Prepare `app_dir` to receive a freshly built bundle.
///
/// The app name is inferred from the entrypoint (or, for generic names like
/// `main.ts`, the project directory), so the output path can collide with an

View on GitHub (pinned to f7822238ca)

Solutions

  1. Note the status text: an exit code like 127/1 usually means a missing library or denied execution, a signal like SIGSEGV means a CEF crash — search the LAUFEY/Deno issue trackers for that exact status.
  2. Re-run with `DENO_LOG=debug` to get backend stderr detail.
  3. Ensure a display is available (run on the desktop session; for CI use xvfb) and on macOS allow the binary in System Settings → Privacy & Security if Gatekeeper blocked it.
  4. Clear the LAUFEY cache directory and rebuild so the backend archive is re-downloaded and checksum-verified fresh.

Example fix

# before
ssh build-server   # then: deno desktop main.ts  -> backend exits, no display

# after (local desktop session, or headless CI with a virtual display)
xvfb-run deno desktop main.ts
Defensive patterns

Strategy: try-catch

Validate before calling

# bash: fail fast in headless environments before launching the GUI backend
if [[ -z "${DISPLAY:-}" && -z "${WAYLAND_DISPLAY:-}" && "$OSTYPE" != darwin* && "$OSTYPE" != msys ]]; then
  echo "no display server available for deno desktop" >&2; exit 1
fi
deno desktop main.ts

Try / catch

# Capture the status text from the error and route it
set +e
OUT="$(DENO_LOG=debug deno desktop main.ts 2>&1)"; RC=$?
set -e
if grep -q "LAUFEY backend exited with status" <<<"$OUT"; then
  echo "backend crash — check the status code above, display env, and laufey cache" >&2
fi
exit $RC

Prevention

When it happens

Trigger: Missing or incompatible LAUFEY runtime payload (corrupted or partial download in the cache); running headless (no DISPLAY on Linux X11, no WAYLAND_DISPLAY) or over plain SSH; CEF sandbox/GPU crash on the host; macOS Gatekeeper quarantining the downloaded backend binary; the runtime dylib path passed via --runtime failing to load.

Common situations: First run on a locked-down CI box or container with no display server; corporate proxy truncating the GitHub release download so the backend binary is incomplete; macOS secu quarantining unsigned binaries from the internet; outdated cached laufey payload after a Deno upgrade.

Related errors


AI-assisted analysis of denoland/deno@f7822238ca (2026-08-20). Data as JSON: /api/errors/606b8a2790cf6166. Report an issue: GitHub.