gitbutlerapp/gitbutler · error · anyhow::Error

Could not resolve application path for '{}'

Error message

Could not resolve application path for '{}'

What it means

After Launch Services returned a URL for the bundle identifier, MacosApplication::find_app_directory calls to_file_path() on it and that conversion returned None. Launch Services handed back a URL that is not a plain file URL, so it cannot be turned into a filesystem path for the .app directory. This is a defensive check that almost never fires on a healthy system.

Source

Thrown at crates/but-api/src/open/program.rs:615

    #[cfg(target_os = "macos")]
    fn find_app_directory(&self) -> anyhow::Result<PathBuf> {
        use objc2_app_kit::NSWorkspace;
        use objc2_foundation::NSString;

        let workspace = NSWorkspace::sharedWorkspace();
        let bundle_identifier = NSString::from_str(&self.bundle_identifier);
        let app_url = workspace
            .URLForApplicationWithBundleIdentifier(&bundle_identifier)
            .ok_or_else(|| {
                anyhow::anyhow!(
                    "Could not find application for '{}'",
                    self.bundle_identifier
                )
            })?;

        app_url.to_file_path().ok_or_else(|| {
            anyhow::anyhow!(
                "Could not resolve application path for '{}'",
                self.bundle_identifier
            )
        })
    }
}

#[cfg(target_os = "macos")]
fn open_in_macos_application(
    app: &MacosApplication,
    cli_arg_supplier: &CliArgumentSupplier,
    open_spec: OpenSpec,
) -> anyhow::Result<()> {
    match open_spec {
        OpenSpec::FileAtLine(path, line_nr) => match app.resolve_cli_wrapper_abspath() {
            Ok(cli_abspath) => {
                let mut cmd = Command::new(cli_abspath);
                cli_arg_supplier.open_at_line(&mut cmd, &path, line_nr);

View on GitHub (pinned to caf1f223d3)

Solutions

1. Reinstall the application so Launch Services points at a normal on-disk .app file URL
2. Inspect what Launch Services returns for the bundle id and remove the stale registration (lsregister dump, then re-register)
3. If it persists, report the case upstream together with the URL Launch Services is returning

match open_in_macos_application(&app, &args, spec) {
    Err(err) if err.to_string().contains("Could not resolve application path") => {
        // treat the registration as broken: prompt reinstall or fall back to `open -b`
    }
    result => result,
}

When it happens

Trigger: URLForApplicationWithBundleIdentifier resolves the bundle id to a non-file URL (custom scheme, network placeholder, or damaged registration) and URL::to_file_path() therefore fails.

Common situations: Exotic or stale Launch Services entries pointing at non-file locations, e.g. after restoring a system from a backup or registering apps via unusual installers; essentially only occurs on damaged system state.

Related errors

• Could not find application for '{}'
• {terminal_name} exited with non-zero status: {status_code}
• Failed to open {terminal_name} ({status_code}): {stderr}
• Unknown terminal: {terminal_id}
• failed to open {paths:?} with app bundle identifier '{}'

AI-assisted analysis of gitbutlerapp/gitbutler@caf1f223d3 (2026-08-20). Data as JSON: /api/errors/7ce3dd2c2308db40. Report an issue: GitHub.