BigPizzaV3/CodexPlusPlus · error · anyhow::Error

GetPackagePathByFullName failed with {}

Error message

GetPackagePathByFullName failed with {}

What it means

package_path_by_full_name resolves an MSIX install path via GetPackagePathByFullName with the same two-call sizing pattern. The first call must return ERROR_INSUFFICIENT_BUFFER; the most common other status is ERROR_NOT_FOUND, meaning no installed package matches the given full name - typically a stale versioned name like App_1.2.3.0_x64__hash after an update.

Source

Thrown at crates/codex-plus-core/src/app_paths.rs:206

    use std::os::windows::ffi::OsStringExt;
    use windows::Win32::Foundation::{ERROR_INSUFFICIENT_BUFFER, ERROR_SUCCESS};
    use windows::Win32::Storage::Packaging::Appx::GetPackagePathByFullName;
    use windows::core::{PCWSTR, PWSTR};

    let full_name = full_name
        .encode_utf16()
        .chain(std::iter::once(0))
        .collect::<Vec<_>>();
    let mut path_length = 0u32;
    let first = unsafe {
        GetPackagePathByFullName(
            PCWSTR(full_name.as_ptr()),
            &mut path_length,
            PWSTR(std::ptr::null_mut()),
        )
    };
    if first != ERROR_INSUFFICIENT_BUFFER {
        bail!("GetPackagePathByFullName failed with {}", first.0);
    }
    let mut path = vec![0u16; path_length as usize];
    let status = unsafe {
        GetPackagePathByFullName(
            PCWSTR(full_name.as_ptr()),
            &mut path_length,
            PWSTR(path.as_mut_ptr()),
        )
    };
    if status != ERROR_SUCCESS {
        bail!("GetPackagePathByFullName failed with {}", status.0);
    }
    let end = path
        .iter()
        .position(|value| *value == 0)
        .unwrap_or(path.len());
    Ok(PathBuf::from(OsString::from_wide(&path[..end])))
}

View on GitHub (pinned to fb3ebd9a82)

Solutions

1. Re-enumerate with GetPackagesByPackageFamily to obtain current full names instead of reusing a cached one
2. Confirm the exact full name via Get-AppxPackage in PowerShell
3. Reinstall the package if Get-AppxPackage shows nothing registered

Example fix

// before - reusing a stale full name captured before an app update
let path = package_path_by_full_name(&cached_full_name)?;

// after - refresh full names from the family, then resolve
let full_names = package_full_names_by_family(&family)?;
let path = full_names.iter()
    .find(|n| n.starts_with(app_name))
    .and_then(|n| package_path_by_full_name(n).ok())
    .ok_or_else(|| anyhow::anyhow!("no installed package matches family {family}"))?;

// Confirm registration before resolving the path
let installed = package_full_names_by_family(&family)?.iter().any(|n| n == &full_name);
anyhow::ensure!(installed, "package {full_name} is not registered for this user");
let path = package_path_by_full_name(&full_name)?;

let path = match package_path_by_full_name(&full_name) {
    Ok(p) => p,
    Err(_) => windows_app_package_roots().into_iter()
        .map(|root| root.join("WindowsApps"))
        .find(|p| p.exists())
        .ok_or_else(|| anyhow::anyhow!("no package path and no WindowsApps fallback"))?,
};

When it happens

Trigger: Passing a package full name captured earlier that no longer matches because an app update changed the version component; a typo'd full name; the package being unregistered for the current user (per-user vs per-machine installs).

Common situations: A cached full name from a previous session reused after the app updated; enumeration and path lookup separated in time; package removed between sessions.

Related errors

• GetPackagesByPackageFamily failed with {}

AI-assisted analysis of BigPizzaV3/CodexPlusPlus@fb3ebd9a82 (2026-08-17). Data as JSON: /api/errors/f80233bba30b305d. Report an issue: GitHub.