astral-sh/uv · error

Failed to fetch credentials for {display_url}

Error message

Failed to fetch credentials for {display_url}

What it means

Raised by `uv token` when the system credential backend (keyring, selected via --keyring-provider) returns nothing for the given URL and username. The provider's async fetch returned None/failed, so no Credentials could be located and the command cannot print a token. The message includes the display URL (and username if not the default __token__ user).

Source

Thrown at crates/uv/src/commands/auth/token.rs:67

        (Some(cli), None) => cli,
        (None, Some(url)) => url.to_string(),
        (None, None) => "__token__".to_string(),
    };
    if username.is_empty() {
        bail!("Username cannot be empty");
    }

    let display_url = if username == "__token__" {
        url.without_credentials().to_string()
    } else {
        format!("{username}@{}", url.without_credentials())
    };

    let credentials = match &backend {
        AuthBackend::System(provider) => provider
            .fetch(url, Some(&username))
            .await
            .ok_or_else(|| anyhow::anyhow!("Failed to fetch credentials for {display_url}"))?,
        AuthBackend::TextStore(store, _lock) => store
            .get_credentials(url, Some(&username))?
            .cloned()
            .ok_or_else(|| anyhow::anyhow!("Failed to fetch credentials for {display_url}"))?,
    };

    let Some(password) = credentials.password() else {
        bail!(
            "No {} found for {display_url}",
            if username != "__token__" {
                "password"
            } else {
                "token"
            }
        );
    };

    writeln!(printer.stdout(), "{password}")?;

View on GitHub (pinned to f1a42680ff)

Solutions

1. Store credentials first with `uv login <url>` (or `uv ... --keyring-provider` flow) so the keyring has an entry for this exact URL and username.
2. Verify the keyring backend works headless: install/start a secret service (gnome-keyring + D-Bus) or use a CLI keyring backend uv can shell out to.
3. Match the username: query with the same `--username` (or URL credentials) that was used when storing; default lookups use `__token__`.
4. Check the exact URL spelling/scheme — keyring entries are keyed per service URL, so https vs http or trailing path differences cause a miss.

Example fix

# before
uv token https://pypi.internal/simple --keyring-provider subprocess  # -> Failed to fetch credentials
# after
uv login https://pypi.internal/simple   # store once
uv token https://pypi.internal/simple --keyring-provider subprocess

# Rust: probe the keyring before running `uv token`
let creds = provider.fetch(url, Some(&username)).await;
if creds.is_none() {
    anyhow::bail!(
        "no keyring entry for {username}@{url}; run `uv login {url}` first"
    );
}

When it happens

Trigger: Running `uv token <url>` with --keyring-provider subprocess while the OS keyring has no entry for that service/username; keyring daemon unavailable or locked (e.g., no D-Bus secret service on a headless Linux box); entry stored under a different username than the one resolved (CLI --username vs URL-embedded vs default __token__).

Common situations: Fresh machine without stored credentials; Linux server without gnome-keyring running; credentials were stored by an older uv under a normalized URL so the lookup key mismatches; username mismatch (stored as __token__ but queried with a real username).

Related errors

• Failed to login with code `{status}`
• Login session timed out after {STATUS_RETRY_LIMIT} seconds

AI-assisted analysis of astral-sh/uv@f1a42680ff (2026-08-16). Data as JSON: /api/errors/f49dae2a0d82edcf. Report an issue: GitHub.