BoundaryML/baml · error

cannot determine directory of current executable

Error message

cannot determine directory of current executable

What it means

`read_host_binary` locates the bundled host binary next to the currently running `baml` executable. `std::env::current_exe()` succeeded, but `Path::parent()` returned `None`, so the crate cannot determine which directory to look in for the host binary. This is an internal invariant violation: a valid executable path virtually always has a parent directory.

Source

Thrown at baml_language/crates/baml_cli/src/pack_command.rs:560

        .collect();
    hits.sort();
    hits.dedup();
    hits.truncate(5);
    hits
}

fn canonicalize_function_name(engine: &BexEngine, name: &str) -> String {
    engine
        .find_user_function(name)
        .map(|info| info.qualified_name)
        .unwrap_or_else(|| name.to_string())
}

fn read_host_binary(target_triple: &str, reporter: &Reporter) -> Result<Vec<u8>> {
    let exe = std::env::current_exe().context("failed to locate current executable")?;
    let dir = exe
        .parent()
        .ok_or_else(|| anyhow!("cannot determine directory of current executable"))?;
    let host_name = host_binary_name(target_triple);
    let host_path = dir.join(&host_name);
    let is_native = target_triple == release_host_target_triple()?;
    if is_native && host_path.exists() {
        return std::fs::read(&host_path)
            .with_context(|| format!("failed to read {}", host_path.display()));
    }

    // A workspace-built host sits next to the CLI but we're skipping it
    // because the requested `--target` isn't this machine's platform, so we
    // download a release host for that target instead. Surface it: a dev who
    // expected their local host embedded would otherwise silently get
    // released bytes — exactly the kind of skip that hides host-side bugs
    // from local testing. (No local host => nothing skipped; stay quiet, the
    // "Downloading" line below already explains the fetch.)
    if !is_native && host_path.exists() {
        reporter.warning(format_args!(
            "ignoring local `{}` (built for this machine) — packing for `{target_triple}` \

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Check what `baml` reports as its executable path (`which baml`, `type baml`) and reinstall/relaunch it from a normal directory rather than a root-level path.
2. Reinstall the BAML CLI from an official release so it sits in a standard bin directory (e.g. ~/.local/bin, /usr/local/bin).
3. If invoked via a wrapper/symlink trick, invoke the real binary path directly instead.
4. If it persists, file a bug with the OS and invocation details — this is effectively an internal invariant violation in `read_host_binary`.

Example fix

// before
let dir = exe
    .parent()
    .ok_or_else(|| anyhow!("cannot determine directory of current executable"))?;
// after (caller-side workaround: install the CLI in a normal location)
// $ mv ./baml /usr/local/bin/baml && baml pack --target <triple>

let exe = std::env::current_exe().context("failed to locate current executable")?;
if exe.parent().is_none() {
    return Err(anyhow!("executable path {:?} has no parent directory; reinstall the CLI in a normal bin directory", exe));
}

fn has_parent_dir(p: &std::path::Path) -> bool { p.parent().is_some() }

match read_host_binary(target_triple, &reporter) {
    Ok(bytes) => use_bytes(bytes),
    Err(e) if e.to_string().contains("cannot determine directory") => reinstall_cli_and_retry(),
    Err(e) => report(e),
}

When it happens

Trigger: Running `baml pack` which calls `read_host_binary(target_triple, reporter)`; `std::env::current_exe()` returns a path with no parent (e.g. a bare root-level or degenerate path) so `exe.parent()` yields `None` and the `ok_or_else` branch fires.

Common situations: The binary was invoked through an exotic exec mechanism that reports a root-like path as the executable (e.g. running the binary as `/baml` at filesystem root, unusual container/namespace setups, or a misbehaving current_exe shim); essentially never seen in normal installs.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• `{}` doesn't look like it belongs to a BAML project — no `ba
• Expected --from '{}' to be a baml_src/ directory, but it doe
• Expected --from '{}' to be a baml_src/ directory, but it is
• failed to clean segmented profiler data at {}
• {err}

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/39722a2b9a35c3e2. Report an issue: GitHub.