gitbutlerapp/gitbutler · warning

Failed to execute command

Error message

Failed to execute command {cmd:?}

What it means

`open_that` tries a sequence of platform opener commands (xdg-open, open, explorer, etc.) with a scrubbed environment and temp cwd; if a command spawns but exits non-zero (`cmd.status().is_ok()` false), it records "Failed to execute command {cmd:?}". If all candidates fail, it bails with the accumulated errors. This indicates the opener program ran but could not open the target (or the platform opener is broken/unavailable).

Solutions

  1. Open the URL/path manually or in a session with a desktop environment (set DISPLAY/WAYLAND_DISPLAY).
  2. Check that a default handler exists: `xdg-mime query default x-scheme-handler/https` and set one with `xdg-settings set default-web-browser …`.
  3. Verify the target file/URL still exists and is accessible.
  4. On headless systems, copy the URL/path from logs instead of relying on the open command.

Example fix

// before
open_url("https://example.com")?; // fails headless
// after
match open_url("https://example.com") {
    Ok(()) => {},
    Err(e) => { eprintln!("Could not open browser ({e}); URL: https://example.com"); }
}
Defensive patterns

Strategy: fallback

Validate before calling

// headless check: skip opening when there is no display (Linux)
if std::env::var_os("DISPLAY").is_none() && std::env::var_os("WAYLAND_DISPLAY").is_none()
    && cfg!(target_os = "linux") {
    eprintln!("no display available; print the URL instead of opening a browser");
    return Ok(());
}

Try / catch

match open_url(url) {
    Err(e) if e.to_string().contains("Failed to execute command") => {
        eprintln!("auto-open failed ({e}); open manually: {url}");
    }
    other => other?,
}

Prevention

When it happens

Trigger: Calling open_url/show_in_finder on a system where the opener command exists but fails: missing desktop environment (headless Linux, SSH session, CI), DISPLAY/WAYLAND not set, the URL/path target doesn't exist or is blocked, or the environment was over-scrubbed so the opener lacks needed variables.

Common situations: Running the desktop tooling over SSH without X/Wayland; containers/headless servers; broken xdg-open configuration (no default handler for the URL scheme); attempting to open files that were deleted.

Related errors


AI-assisted analysis of gitbutlerapp/gitbutler@58e5313667 (2026-09-18). Data as JSON: /api/errors/53940538cfbd23ff. Report an issue: GitHub.

Appendix: source

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

            "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 58e5313667)