gitbutlerapp/gitbutler · error

Failed to execute command {cmd:?}

Error message

Failed to execute command {cmd:?}

What it means

open_that() opens a URL or file with the platform opener: it asks the open crate for candidate commands (xdg-open/gio/kde-open on Linux, open on macOS) and runs each with a sanitized environment (AppImage/temp-mount paths stripped from PATH-like vars). If every candidate fails even to spawn (cmd.status() returns Err), the collected per-command failures are returned.

Source

Thrown at crates/but-api/src/open/mod.rs:124

            "GTK_DATA_PREFIX",
            "GTK_EXE_PREFIX",
            "GTK_IM_MODULE_FILE",
            "GTK_PATH",
            "LD_LIBRARY_PATH",
            "PATH",
            "PERLLIB",
            "PYTHONHOME",
            "PYTHONPATH",
            "QT_PLUGIN_PATH",
            "XDG_DATA_DIRS",
        ]);

        cmd.envs(cleaned_vars);
        cmd.current_dir(env::temp_dir());
        if cmd.status().is_ok() {
            return Ok(());
        } else {
            cmd_errors.push(anyhow::anyhow!("Failed to execute command {cmd:?}"));
        }
    }
    if !cmd_errors.is_empty() {
        bail!("Errors occurred: {cmd_errors:?}");
    }
    Ok(())
}

/// Opens supported editor URLs directly inside WSL.
///
/// The normal URL opener can fail to route `vscode://file/...`-style URLs back
/// to Linux editor CLIs when GitButler runs in WSL, so this attempts a direct
/// invocation first. Returns `true` only when a supported editor command was
/// executed successfully; unsupported URLs and failed launches fall back to the
/// generic opener.
fn open_editor_url_as_command_invocation_on_wsl(target_url: &Url) -> bool {
    use std::process::Command;

View on GitHub (pinned to 2497b8007a)

Solutions

1. Install xdg-utils so xdg-open exists (Debian/Ubuntu: apt install xdg-utils; Fedora: dnf install xdg-utils)
2. Set BROWSER and run within a desktop session so the open crate has a usable candidate
3. Prefer the dedicated open-editor/open-terminal APIs that target specific binaries instead of the generic URL opener
4. For AppImage/sandbox deployments, verify the opener's path survives the environment cleaning

Example fix

# before: generic open fails in a headless/minimal environment

# after: provide an opener
sudo apt install xdg-utils
export BROWSER=firefox   # and/or run inside a desktop session

let opener_available = which::which("xdg-open").is_ok()
    || which::which("gio").is_ok()
    || std::env::var_os("BROWSER").is_some();
if !opener_available {
    // skip generic open; offer copy-to-clipboard or a specific editor instead
}

match open_that(&url) {
    Err(err) if err.to_string().starts_with("Errors occurred") => {
        // fall back: copy the URL/path, or launch a known editor binary directly
    }
    other => other,
}

When it happens

Trigger: Minimal or headless Linux with no xdg-utils installed; PATH cleaning removed the directory holding the only opener; AppImage-hostile environments; BROWSER unset with no desktop portal available.

Common situations: Running in containers or SSH sessions without desktop integration; distros lacking xdg-utils; sandboxed AppImage deployments where the opener path is filtered out.

Related errors

• Failed to parse URL
• Would probably need to run "ln -sf '{}' '{UNIX_LINK_PATH}'"{
• DefaultTerminalNotFound
• system clock is before the Unix epoch: {err}
• fetch timestamp does not fit in the database: {err}

AI-assisted analysis of gitbutlerapp/gitbutler@2497b8007a (2026-08-17). Data as JSON: /api/errors/53940538cfbd23ff. Report an issue: GitHub.