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
- Ensure the sidecar core binaries are downloaded/linked: run `pnpm prepare:check` (or the repo's prepare script) so `backend/tauri/sidecar/` is populated.
- Check the binary exists and is executable (`chmod +x` on Unix; unblock/quarantine removal on Windows/macOS).
- Verify the architecture of the sidecar matches the host; re-download the correct core.
- 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
- Run the repo's prepare/sidecar download script after fresh clones and worktrees
- Verify sidecar architecture matches the host before shipping
- Check quarantine/AV status of downloaded cores on macOS/Windows
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
- application failed to start
- {} not found
- semaphore should never closed
- version overflow
- prepare() called more than once with different identifiers.
AI-assisted analysis of libnyanpasu/clash-nyanpasu@f7dbce2997 (2026-09-08).
Data as JSON: /api/errors/bf52ada543365f93.
Report an issue: GitHub.