libnyanpasu/clash-nyanpasu · error

failed to execute sidecar command

Error message

failed to execute sidecar command

What it means

`collect_envs` runs the bundled mihomo/clash sidecar binary with `-v`/`-V` to harvest version info and unwraps `Command::output()` with this message. The expect panics if the child process cannot be spawned or waited on — typically because the sidecar executable is missing, not executable, or the platform spawn call fails. This is a startup/environment error surfaced as a hard panic rather than a Result.

Source

Thrown at backend/tauri/src/utils/collect.rs:78

        memory: Cow::Owned(SizeFormatter::new(system.total_memory(), BINARY).to_string()),
    };

    let mut core = BTreeMap::new();
    for c in CoreType::get_supported_cores() {
        let name: &str = c.as_ref();

        let mut command = std::process::Command::new(
            super::dirs::get_data_or_sidecar_path(name)
                .map_err(|e| std::io::Error::other(e.to_string()))?,
        );
        command.args(if matches!(c, CoreType::Clash(ClashCoreType::ClashRust)) {
            ["-V"]
        } else {
            ["-v"]
        });
        #[cfg(windows)]
        let command = command.creation_flags(0x08000000);
        let output = command.output().expect("failed to execute sidecar command");
        let stdout = String::from_utf8_lossy(&output.stdout);
        core.insert(
            Cow::Borrowed(name),
            Cow::Owned(stdout.replace("\n\n", " ").trim().to_owned()),
        );
    }
    Ok(EnvInfo {
        os: Cow::Owned(
            format!(
                "{} {}",
                System::long_os_version().unwrap_or("".to_string()),
                System::kernel_version().unwrap_or("".to_string()),
            )
            .trim()
            .to_owned(),
        ),
        arch: Cow::Owned(System::cpu_arch()),
        core,

View on GitHub (pinned to f7dbce2997)

Solutions

  1. Ensure the sidecar core binaries are downloaded/linked: run `pnpm prepare:check` (or the repo's prepare script) so `backend/tauri/sidecar/` is populated.
  2. Check the binary exists and is executable (`chmod +x` on Unix; unblock/quarantine removal on Windows/macOS).
  3. Verify the architecture of the sidecar matches the host; re-download the correct core.
  4. Handle the error gracefully by replacing `.expect(...)` with error propagation/logging so missing sidecars degrade instead of panicking.

Example fix

// before
let output = command.output().expect("failed to execute sidecar command");
// after
let output = command.output().map_err(|e| {
    anyhow::anyhow!("failed to execute sidecar command: {e}")
})?;
Defensive patterns

Strategy: fallback

Validate before calling

let sidecar = sidecar_path.as_ref();
if !sidecar.exists() {
    eprintln!("sidecar binary missing: {}", sidecar.display());
}
#[cfg(unix)]
{
    use std::os::unix::fs::PermissionsExt;
    let mode = sidecar.metadata().map(|m| m.permissions().mode());
    if !matches!(mode, Some(m) if m & 0o111 != 0) {
        eprintln!("sidecar binary is not executable");
    }
}

Try / catch

let output = match command.output() {
    Ok(o) => o,
    Err(e) => {
        tracing::warn!("sidecar spawn failed: {e}; skipping env collection");
        return;
    }
};

Prevention

When it happens

Trigger: Calling `collect_envs` when the sidecar binary path does not exist (download/symlink step skipped, e.g. fresh checkout without `pnpm prepare:check`), the file lacks the execute bit (Linux/macOS) or is blocked/quarantined (Windows/macOS Gatekeeper), or the OS resource limits prevent process creation.

Common situations: Building in a fresh worktree where `backend/tauri/sidecar/` was not populated; antivirus or quarantine attributes blocking the downloaded core; wrong architecture binary (arm64 vs x64); running from a stripped package that excluded the sidecar resources.

Related errors


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