tauri-apps/tauri · error

failed to get exe directory

Error message

failed to get exe directory

What it means

`resource_dir_from` computes the resource directory from the current executable path by taking `exe.as_ref().parent()`, which returns `None` for a bare file name with no parent directory. The `expect` panics with this message in that case. It effectively means the exe path handed to `resource_dir()` has no parent component.

Solutions

1. Launch the app via a path that includes its directory (e.g. `./target/debug/myapp` instead of `myapp`)
2. In tests/custom callers, pass a full absolute path to `resource_dir_from` instead of a bare filename
3. Use `std::env::current_exe()` to obtain a fully qualified exe path

Example fix

// before
resource_dir_from(PathBuf::from("myapp"), &pkg_info, &env)
// after
resource_dir_from(std::env::current_exe().unwrap(), &pkg_info, &env)

let exe = std::env::current_exe().unwrap();
assert!(exe.parent().is_some(), "exe path must include a directory");

fn exe_path_has_parent(exe: &std::path::Path) -> bool {
  exe.parent().map(|p| !p.as_os_str().is_empty()).unwrap_or(false)
}

When it happens

Trigger: Calling `tauri::path::resource_dir()` (or `resource_dir_from`) when the exe path is a single component like `"myapp"` or `""` — no directory separator — so `Path::parent()` yields `None`.

Common situations: Running the binary via a bare name resolved through PATH in unusual environments; embedding tauri in tests with a stub exe path like `PathBuf::from("app")`; exotic process launching that reports a relative bare filename.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors

• failed to canonicalize global API script path
• failed to read plugin global API script paths
• failed to write checked_features file
• failed to write global API script
• Tauri "Isolation" Pattern only supports relative or…

AI-assisted analysis of tauri-apps/tauri@460ec35447 (2026-09-18). Data as JSON: /api/errors/d1610f7821ef76a2. Report an issue: GitHub.

Appendix: source

Thrown at crates/tauri-utils/src/platform.rs:286

  {
    let exe = current_exe()?;
    resource_dir_from(exe, package_info, env)
  }
}

#[cfg(target_os = "android")]
fn resource_dir_android(_package_info: &PackageInfo, _env: &Env) -> crate::Result<PathBuf> {
  Ok(PathBuf::from(ANDROID_ASSET_PROTOCOL_URI_PREFIX))
}

#[cfg(not(target_os = "android"))]
#[allow(unused_variables)]
fn resource_dir_from<P: AsRef<std::path::Path>>(
  exe: P,
  package_info: &PackageInfo,
  env: &Env,
) -> crate::Result<PathBuf> {
  let exe_dir = exe.as_ref().parent().expect("failed to get exe directory");
  let curr_dir = exe_dir.display().to_string();

  let parts: Vec<&str> = curr_dir.split(std::path::MAIN_SEPARATOR).collect();
  let len = parts.len();

  // Check if running from the Cargo output directory, which means it's an executable in a development machine
  // We check if the binary is inside a `target` folder which can be either `target/$profile` or `target/$triple/$profile`
  // and see if there's a .cargo-lock file along the executable
  // This ensures the check is safer so it doesn't affect apps in production
  // Windows also includes the resources in the executable folder so we check that too
  if cfg!(target_os = "windows")
    || ((len >= 2 && parts[len - 2] == "target") || (len >= 3 && parts[len - 3] == "target"))
      && is_cargo_output_directory(exe_dir)
  {
    return Ok(exe_dir.to_path_buf());
  }

  #[allow(unused_mut, unused_assignments)]

View on GitHub (pinned to 460ec35447)