What causes "Hub registration failed with status {status}" in atuinsh/atuin?

Check the HTTP status in the message for the class of failure (4xx client vs 5xx server).

Hub registration failed with status

Error message

Hub registration failed with status {status}

What it means

Fallback error in `register` (crates/atuin-client/src/auth.rs:353): the Hub returned a non-success HTTP status, but the response body could NOT be parsed as a `HubErrorResponse` (empty body, HTML error page, or unexpected JSON shape). The status code is the only diagnostic available.

Solutions

Check the HTTP status in the message for the class of failure (4xx client vs 5xx server).
Check Atuin Hub status / retry later if 5xx.
Ensure client and server versions are compatible (`atuin --version`); update if old.
Inspect network path for proxies that could alter the response body.

Example fix

// before
bail!("Hub registration failed with status {status}");
// after: capture body text for diagnosis
let body = resp.text().await.unwrap_or_default();
bail!("Hub registration failed with status {status}: {body}");

Defensive patterns

Strategy: retry

Validate before calling

// Verify connectivity and server reachability before registering
let probe = reqwest::get(format!("{hub_url}/api/v0/register")).await;
let reachable = matches!(probe, Ok(r) if !r.status().is_server_error());

Try / catch

match client.register(u, e, p).await {
    Err(e) if e.to_string().contains("failed with status 5") => {
        // server-side / unparseable response: retry with backoff
    }
    Err(e) => eprintln!("registration failed: {e}"),
    Ok(_) => { /* success */ }
}

Prevention

Monitor Atuin Hub status before account operations.
Avoid proxies that rewrite error response bodies.
Keep client and Hub versions aligned.
Back off and retry on 5xx/429 instead of hammering the endpoint.

When it happens

Trigger: POST to `/api/v0/register` fails with any non-2xx status and a body that fails `resp.json::<HubErrorResponse>()` — e.g. 500 from a proxy, 429 rate limit with an empty body, or a reverse proxy returning an HTML error page.

Common situations: Hub outage or maintenance; intermediate proxies/load balancers swallowing the JSON error body; running a client version against a Hub version with different error schema; aggressive registration rate limiting.

Related errors

AI-assisted analysis of atuinsh/atuin@900007c480 (2026-09-19). Data as JSON: /api/errors/241e465cd8591238. Report an issue: GitHub.

Appendix: source

Thrown at crates/atuin-client/src/auth.rs:353

            .send()
            .await
            .context("failed to connect to Atuin Hub")?;

        let status = resp.status();

        if status.is_success() {
            let reg: RegisterResponse = resp.json().await?;
            return Ok(AuthResponse::Success {
                session: reg.session,
                auth_type: reg.auth,
            });
        }

        if let Ok(err) = resp.json::<HubErrorResponse>().await {
            bail!("{}", err.reason);
        }

        bail!("Hub registration failed with status {status}");
    }

    async fn change_password(
        &self,
        current_password: &str,
        new_password: &str,
        totp_code: Option<&str>,
    ) -> Result<MutateResponse> {
        let hub_token = self.hub_token.as_deref().ok_or_else(|| {
            eyre::eyre!("Not logged in to Atuin Hub. Please run 'atuin login' to authenticate.")
        })?;

        if !hub_token.starts_with("atapi_") {
            bail!(
                "Your Hub session token is invalid. Please run 'atuin login' to re-authenticate \
                 with Atuin Hub."
            );
        }

View on GitHub (pinned to 900007c480)