Kimi For Coding device authorization failed: ${response.stat

Error message

Kimi For Coding device authorization failed: ${response.status}${text ? ` ${text}` : ''}

What it means

startKimiCodingDeviceLogin POSTs the device-authorization request to Kimi's OAuth endpoint. On a non-ok HTTP status it throws with the status code and any response body text, signaling the device flow could not even be started (before any user code exists).

Source

Thrown at mastracode/sdk/src/auth/providers/kimi-coding.ts:124

export async function startKimiCodingDeviceLogin(options?: {
  signal?: AbortSignal;
}): Promise<KimiCodingDeviceLoginPending> {
  const clientId = CLIENT_ID;
  const deviceId = createKimiCodingDeviceId();
  const response = await fetch(`${OAUTH_HOST}/api/oauth/device_authorization`, {
    method: 'POST',
    headers: {
      ...getKimiCodingDeviceHeaders(deviceId),
      'Content-Type': 'application/x-www-form-urlencoded',
      Accept: 'application/json',
    },
    body: new URLSearchParams({ client_id: clientId }).toString(),
    signal: requestSignal(options?.signal),
  });
  if (!response.ok) {
    const text = await response.text().catch(() => '');
    throw new Error(`Kimi For Coding device authorization failed: ${response.status}${text ? ` ${text}` : ''}`);
  }

  const data = await readJson(response);
  const deviceCode = data?.device_code;
  const userCode = data?.user_code;
  const verificationUri = trustedHttpUrl(data?.verification_uri);
  const verificationUriComplete = trustedHttpUrl(data?.verification_uri_complete);
  if (
    typeof deviceCode !== 'string' ||
    !deviceCode ||
    typeof userCode !== 'string' ||
    !userCode ||
    !verificationUri ||
    !verificationUriComplete
  ) {
    throw new Error('Invalid Kimi For Coding device authorization response');
  }

View on GitHub (pinned to 75dd419e61)

Solutions

Read the embedded status/body: 400/401 usually means the client_id is rejected — update the SDK or check Kimi's API status
Retry with backoff if the status is 429/5xx
Verify network access to the Kimi authorization endpoint (bypass proxies/VPN to test)
Re-run the login flow; device authorization is a fresh request each time

Example fix

// before
const pending = await startKimiCodingDeviceLogin(); // 429
// after
await new Promise(r => setTimeout(r, 5000));
const pending = await startKimiCodingDeviceLogin(); // retry once after backoff

Defensive patterns

Strategy: retry

Validate before calling

// Pre-flight: confirm the auth endpoint is reachable before starting the device flow
const ping = await fetch(authBaseUrl, { method: 'HEAD' }).catch(() => null);
if (!ping) throw new Error('Kimi auth endpoint unreachable — check network/proxy before login');

Type guard

function isDeviceAuthHttpError(err: unknown): err is Error & { status?: number } {
  const m = err instanceof Error ? err.message.match(/device authorization failed: (\d{3})/) : null;
  return m !== null;
}

Try / catch

try {
  pending = await startKimiCodingDeviceLogin();
} catch (err) {
  const m = err instanceof Error && err.message.match(/device authorization failed: (\d{3})/);
  if (m && (m[1].startsWith('5') || m[1] === '429')) {
    await backoff(); pending = await startKimiCodingDeviceLogin(); // retry transient
  } else throw err; // 400/401: client_id or config problem, don't retry
}

Prevention

Use exponential backoff for 429/5xx on the authorization request
Verify outbound network access to the Kimi auth endpoint (corporate proxies often block it)
Keep the SDK updated in case the embedded client_id changes
Fail fast on 4xx — retrying invalid-client errors never helps

When it happens

Trigger: The device authorization endpoint returns non-2xx: invalid/expired client_id (401/400), server outage (5xx), rate limiting (429), or a network middlebox returning an error page. Called via the 'pending' login path for Kimi For Coding.

Common situations: Embedded client_id no longer accepted after a Kimi API update; corporate proxy/firewall blocking the auth endpoint; transient 5xx or 429 during heavy use; wrong region/base URL configuration.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/f4368d87a3ef4e4a. Report an issue: GitHub.