What causes "{bin} get failed for {server}: {}" in jdx/mise?

Reproduce directly: `echo | docker-credential- get` — fix whatever error it prints

{bin} get failed for {server}: {}

Error message

{bin} get failed for {server}: {}

What it means

mise delegates registry credential lookup to a Docker credential helper (e.g. docker-credential-desktop, docker-credential-ghcr, docker-credential-win-credential-desktop) configured under `credHelpers`/`credsStore` in ~/.docker/config.json. It spawns `<bin> get`, writes the server name to the helper's stdin, and requires exit status 0; a non-zero exit surfaces the helper's stderr here. Spawn failures are a separate, earlier error.

Source

Thrown at src/oci/auth.rs:261

    let mut command = Command::new(&bin);
    command
        .arg("get")
        .stdin(Stdio::piped())
        .stdout(Stdio::piped())
        .stderr(Stdio::piped());
    prepare_noninteractive_child(&mut command);
    let mut child = command
        .spawn()
        .wrap_err_with(|| format!("spawning {bin} (from credHelpers/credsStore)"))?;
    let _running_pid = RunningPidGuard::new(Some(child.id()));
    {
        use std::io::Write;
        let mut stdin = child.stdin.take().expect("stdin piped");
        stdin.write_all(server.as_bytes())?;
    }
    let out = child.wait_with_output()?;
    if !out.status.success() {
        bail!(
            "{bin} get failed for {server}: {}",
            String::from_utf8_lossy(&out.stderr).trim()
        );
    }
    #[derive(Deserialize)]
    struct HelperResponse {
        #[serde(rename = "Username")]
        username: String,
        #[serde(rename = "Secret")]
        secret: String,
    }
    let resp: HelperResponse = serde_json::from_slice(&out.stdout)
        .wrap_err_with(|| format!("parsing {bin} get output"))?;
    Ok(Credential {
        username: resp.username,
        secret: resp.secret,
    })
}

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

Reproduce directly: `echo <server> | docker-credential-<name> get` — fix whatever error it prints
Re-authenticate: `docker login <server>` to refresh the stored credential
Unlock the OS keychain / ensure the session can access it (common over SSH)
Remove or correct the `credsStore`/`credHelpers` entry in ~/.docker/config.json if you don't want mise to use it

Defensive patterns

Strategy: fallback

Validate before calling

echo -n <server> | docker-credential-<name> get >/dev/null 2>&1 || echo "helper will fail for <server> — docker login <server> first"

Try / catch

Treat this error as 'no credential available from helper': catch it, warn with the helper stderr, and fall back to the next auth source (auths entry, MISE_OCI_* env creds) or prompt — do not retry the helper unchanged.

Prevention

Run `docker login <server>` before `mise oci push` on each new machine/CI runner
Unlock the OS keychain when operating over SSH sessions
Test credential helpers after Docker Desktop upgrades — their config sometimes references removed helpers

When it happens

Trigger: Running `mise oci push` (or registry auth) with a credsStore/credHelper whose `get` fails: expired/absent stored credentials, a locked OS keychain (macOS Keychain, Windows Credential Manager), missing server entry, or the helper erroring out for that server.

Common situations: Keychain locked or SSH session without keychain unlock; credentials expired since last `docker login`; helper configured by Docker Desktop but misbehaving on Linux servers; helper expects a different server string than the one mise sent (host vs host:port).

Related errors

AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/ba0e3a09f50df96d. Report an issue: GitHub.