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
- Inspect the HTTP status and body in the message: 5xx → retry with backoff; 429 → wait and retry; 401/403 → fix client/deployment auth config
- Verify the device-code endpoint configuration (client_id, scopes, base URL)
- Check auth service health/status page before repeated retries
- 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
- Retry only transient statuses (429, 5xx); fail fast on 401/403
- Monitor auth service health before initiating logins
- Validate client_id/endpoint config server-side to avoid repeated rejections
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
- send failed: {body}
- screen query failed: {body}
- resize failed: {body}
- wait failed: {body}
- stop failed: {body}
AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31).
Data as JSON: /api/errors/f813045a443e92f4.
Report an issue: GitHub.