denoland/deno · error
could not find ' ' backend binary under (set via )
Error message
could not find '{backend}' backend binary under {} (set via {}) What it means
When the LAUFEY_DEV_DIR environment variable is set, `deno desktop` uses that laufey source checkout instead of downloading a release, resolving the backend binary with locate_dev_backend_binary(). This error means the env var pointed at a directory that contains no buildable/located binary for the requested backend — typically a checkout that has not been cargo-built yet.
Solutions
- Build the backend in the dev checkout: run laufey's own build (e.g. cargo build --release) inside $LAUFEY_DEV_DIR so the expected binary layout exists.
- If you did not intend dev mode, unset LAUFEY_DEV_DIR and re-run to fall back to the cached/download path.
- Verify the path actually points at a laufey checkout (look for its Cargo.toml and build output dirs) and fix the env var.
- Request the same backend you built for in the dev checkout.
Example fix
# before export LAUFEY_DEV_DIR=~/src/laufey # fresh clone, never built deno desktop # error: could not find 'wry' backend binary under /home/me/src/laufey (set via LAUFEY_DEV_DIR) # after — option A: build it (cd ~/src/laufey && cargo build --release) && deno desktop # after — option B: leave dev mode unset LAUFEY_DEV_DIR && deno desktop
Defensive patterns
Strategy: validation
Validate before calling
# If LAUFEY_DEV_DIR is set, assert the checkout actually contains the backend build
if [ -n "$LAUFEY_DEV_DIR" ]; then
find "$LAUFEY_DEV_DIR" -type f -name '*laufey*' -perm -u+x | head -1 >/dev/null \
|| { echo "LAUFEY_DEV_DIR set but no built backend found — run cargo build or unset it"; exit 1; }
fi Prevention
- Scope LAUFEY_DEV_DIR to the specific command that needs it (LAUFEY_DEV_DIR=... deno desktop) instead of exporting it in your shell profile.
- Re-run the laufey build (cargo build) after pulling or cargo clean-ing the dev checkout.
- Remember the env var shadows the verified download path entirely — if you did not mean dev mode, unset it.
When it happens
Trigger: LAUFEY_DEV_DIR is exported (e.g. to hack on laufey) but the checkout has never been built, was cleaned with cargo clean, or was built only for a different backend than the one requested on the command line.
Common situations: A developer exports LAUFEY_DEV_DIR in their shell profile, then clones a fresh laufey checkout and forgets `cargo build`; CI caches a dev dir but the build step was skipped; the env var survived from an old experiment and now shadows the working download path.
Related errors
- could not find ' ' .app bundle under (set via )
- no pinned SHA-256 for
- build failed (exit code: )
- checksum mismatch for
- cli/laufey_sums.lock has no pinned laufey version —…
AI-assisted analysis of denoland/deno@f7822238ca (2026-08-20).
Data as JSON: /api/errors/7d0fae28d6ceca60.
Report an issue: GitHub.
Appendix: source
Thrown at cli/tools/desktop.rs:2090
);
}
Ok(dir)
}
/// Locate the LAUFEY backend binary for `backend` on `target`.
///
/// Resolution order: `LAUFEY_DEV_DIR` checkout → cached download →
/// fresh download.
async fn find_binary(
&self,
backend: &str,
target: &str,
) -> Result<PathBuf, AnyError> {
if let Some(dev_dir) = laufey_dev_dir() {
let binary =
locate_dev_backend_binary(&dev_dir, backend).ok_or_else(|| {
deno_core::anyhow::anyhow!(
"could not find '{backend}' backend binary under {} (set via {})",
dev_dir.display(),
LAUFEY_DEV_DIR_ENV
)
})?;
// Re-sign the dev laufey build so its identifier matches the bundle
// id — same fix as the download path, applied every launch
// because a fresh `cargo build` of laufey restores the linker's
// default `Identifier=laufey`. The harmonize call is idempotent:
// already-correct binaries are skipped.
#[cfg(target_os = "macos")]
if let Some(laufey_app) = laufey_app_for_binary(&binary)
&& let Err(e) = harmonize_laufey_app_identifiers(&laufey_app)
{
log::warn!(
"[desktop] could not re-sign dev laufey backend: {e} \
(notifications may not work in HMR mode)"
);View on GitHub (pinned to f7822238ca)