libnyanpasu/clash-nyanpasu · error

failed to get app_path

Error message

failed to get app_path

What it means

init_launch converts the canonicalized executable path's OsStr to a Rust String for the auto-launch registration. If the path contains bytes that are not valid UTF-16/UTF-8 convertible (on Windows paths are WTF-16; non-Unicode sequences fail to_str), the error is thrown. It blocks configuring system auto-start.

Source

Thrown at backend/tauri/src/core/sysopt.rs:227

    pub fn init_launch(&self) -> Result<()> {
        let enable = { Config::verge().latest().enable_auto_launch };
        let enable = enable.unwrap_or(false);

        log::info!(target: "app", "Initializing auto-launch with enable={}", enable);

        let app_exe = current_exe()?;
        let app_exe = dunce::canonicalize(app_exe)?;
        log::debug!(target: "app", "Resolved app executable path: {:?}", app_exe);

        let app_name = app_exe
            .file_stem()
            .and_then(|f| f.to_str())
            .ok_or(anyhow!("failed to get file stem"))?;

        let app_path = app_exe
            .as_os_str()
            .to_str()
            .ok_or(anyhow!("failed to get app_path"))?
            .to_string();

        log::debug!(target: "app", "Initial app path: {}", app_path);

        // fix issue #26
        #[cfg(target_os = "windows")]
        let app_path = format!("\"{app_path}\"");
        #[cfg(target_os = "windows")]
        log::debug!(target: "app", "Windows formatted app path: {}", app_path);

        // use the /Applications/Clash Nyanpasu.app path
        #[cfg(target_os = "macos")]
        let app_path = (|| -> Option<String> {
            let path = std::path::PathBuf::from(&app_path);
            let path = path.parent()?.parent()?.parent()?;
            let extension = path.extension()?.to_str()?;
            match extension == "app" {
                true => Some(path.as_os_str().to_str()?.to_string()),

View on GitHub (pinned to f7dbce2997)

Solutions

1. Relocate the application to a path using standard Unicode characters
2. Use to_string_lossy() if approximate paths are acceptable for auto-launch
3. Skip auto-launch registration with a clear log instead of failing hard

Example fix

// before
let app_path = app_exe.as_os_str().to_str().ok_or(anyhow!("failed to get app_path"))?.to_string();
// after
let app_path = app_exe.to_string_lossy().into_owned();

let exe = std::env::current_exe()?;
if exe.to_str().is_none() {
    eprintln!("executable path {:?} is not valid UTF-8; auto-launch registration may fail", exe);
}

fn path_is_utf8(p: &std::path::Path) -> bool {
    p.as_os_str().to_str().is_some()
}

match init_launch(app_exe) {
    Ok(launch) => launch,
    Err(e) if e.to_string().contains("app_path") => /* fall back to to_string_lossy or skip auto-launch with warning */,
    Err(e) => return Err(e),
}

When it happens

Trigger: update_launch -> init_launch when the app executable path contains characters unrepresentable as UTF-8 (rare malformed Windows path components), so app_exe.as_os_str().to_str() returns None.

Common situations: Executables placed in folders with corrupted or mixed-encoding names, unusual unattended installs, or portable builds run from mapped drives with odd names.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

• path is not valid UTF-8: {}
• failed to get file stem
• non-UTF-8 source
• non-UTF-8 destination
• destination path has no file name: {}

AI-assisted analysis of libnyanpasu/clash-nyanpasu@f7dbce2997 (2026-09-08). Data as JSON: /api/errors/2db143589d751e07. Report an issue: GitHub.