xai-org/grok-build · error

Device code request failed (HTTP {status}): {body}

Error message

Device code request failed (HTTP {status}): {body}

What it means

request_device_code treats any non-success, non-404 HTTP status from the device-code endpoint as a hard failure, including the status code and up-to-the-full response body in the message. This surfaces server-side rejection details (rate limits, bad client config, outages) to the caller of run_device_code_login_channels.

Source

Thrown at crates/codegen/xai-grok-shell/src/auth/device_code.rs:166

            // headless automation in the device-flow funnel metrics.
            .header("x-grok-client-surface", surface.as_str())
            .form(&[
                ("client_id", client_id),
                ("scope", scope_str.as_str()),
                ("referrer", "grok-build"),
            ]),
        &url,
    )
    .send()
    .await?;

    if !resp.status().is_success() {
        let status = resp.status();
        let body = resp.text().await.unwrap_or_default();
        if status.as_u16() == 404 {
            anyhow::bail!(DeviceCodeError::NotEnabled);
        }
        anyhow::bail!("Device code request failed (HTTP {status}): {body}");
    }

    let server_resp: DeviceCodeResponse = resp.json().await?;

    // Defend against control characters from a malicious issuer.
    if !server_resp
        .user_code
        .chars()
        .all(|c| c.is_ascii_alphanumeric() || c == '-')
    {
        anyhow::bail!("Server returned invalid user_code format (expected [A-Z0-9-])");
    }

    validate_verification_uri(&server_resp.verification_uri)?;
    if let Some(ref verification_uri_complete) = server_resp.verification_uri_complete {
        validate_verification_uri(verification_uri_complete)?;
    }

View on GitHub (pinned to bc7f02eddd)

Solutions

  1. Inspect the HTTP status and body in the message: 5xx → retry with backoff; 429 → wait and retry; 401/403 → fix client/deployment auth config
  2. Verify the device-code endpoint configuration (client_id, scopes, base URL)
  3. Check auth service health/status page before repeated retries
  4. Fall back to `grok login` or XAI_API_KEY while the endpoint is unhealthy
Defensive patterns

Strategy: retry

Try / catch

match request_device_code(&client, &cfg).await {
    Ok(dc) => dc,
    Err(e) => {
        let msg = e.to_string();
        if msg.contains("HTTP 429") || msg.contains("HTTP 5") {
            tokio::time::sleep(Duration::from_secs(5)).await;
            request_device_code(&client, &cfg).await?
        } else {
            return Err(e); // 401/403: config problem, don't retry
        }
    },
}

Prevention

When it happens

Trigger: Calling request_device_code when the endpoint returns non-2xx other than 404 — e.g. 401/403 (client auth rejected), 429 (rate limited), 5xx (server error) — with the response body embedded in the error.

Common situations: Auth server outage or maintenance, incorrect client_id/audience configured server-side, exceeding device-code issuance rate limits, or a reverse proxy returning 502/503.

Related errors


AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/f813045a443e92f4. Report an issue: GitHub.