[Feature]: Add xAI (Grok) account sign-in via OAuth Device Code for headless hubs

Abierto
  • ¿Algo no está bien?
#8,554 1 comentario 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
authentication, backend-api-design

Línea de trabajo

Start by reading the existing xAI OAuth account flow and the related device-code issues #3366 and #8082. Confirm whether xAI's OAuth discovery document advertises a device authorization endpoint, then trace the proxy, account-pool, CLI, and dashboard entry points for adding an authentication flow. Done means the flow polls and handles authorization outcomes, stores successful accounts consistently, and leaves no partial account after failure or cancellation.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

account-pool enhancement
Area

Authentication and account pool

What are you trying to accomplish?

Add xAI (Grok) account authorization via the OAuth 2.0 Device Authorization Grant (RFC 8628, "Device Code") to OpenCodex, so an operator can connect a Grok/xAI account to a headless or remote hub (no local browser, no callback URL to paste) by entering a short code on any other device.

What prevents this today?

The xAI provider only offers the browser-redirect OAuth flow. On a headless or remote hub (for example a k3s pod or an SSH-only server) the redirect target is not reachable from the operator's browser, so the account cannot be added through the dashboard or ocx without workarounds. The same limitation was already raised for ChatGPT/Codex in #3366 and for Codex-only device-code auth in #8082; Grok has no equivalent path.

What should OpenCodex do?
  • Provider xai (account pool) offers a "Sign in with device code" action next to the existing OAuth action.
  • The proxy requests a device code from the xAI authorization endpoint and shows:
    • verification_uri (and verification_uri_complete when provided),
    • user_code,
    • expires_in countdown.
  • The proxy polls the token endpoint at the advertised interval, honours slow_down by increasing the interval, and stops on expired_token / access_denied with a clear message.
  • On success the tokens are stored in the account pool exactly like the existing xAI OAuth accounts (same refresh, same expiry handling, same ocx account list visibility).
  • The same flow is available from the CLI for headless hubs, with the code and URL printed to stdout and no callback port required.
  • Failure and cancellation leave no partial account in the pool.
Example usage or interface
# Headless hub, no browser on the host
ocx account add --provider xai --device-code
# Expected output (example):
#   Open https://accounts.x.ai/device and enter code: ABCD-EFGH (expires in 600s)
#   Waiting for authorization...
#   Authorized: account xai-1 added to pool "xai"
ocx account list --provider xai --json

Dashboard: Providers → xAI → Add account → "Sign in with device code" shows the URL and code and updates its status until authorized.

Alternatives or workarounds
  • Run the browser OAuth flow on a laptop and copy the stored credential file to the hub. This is manual, bypasses the account-pool bookkeeping, and breaks on token rotation.
  • SSH port-forwarding for the OAuth callback port. This is fragile and does not work when the callback host differs from the hub.
Additional context
  • Related: #3366 (ChatGPT/Codex device code for headless hubs, closed), #8082 (device-code-only Codex auth, open), #3898 (headless hub reauth).
  • Requested by an operator running OpenCodex on a remote k3s hub.
  • Implementation note for maintainers: confirm that xAI's OAuth server advertises the device authorization endpoint in its discovery document before implementing; this request does not assume a specific endpoint URL.
Checks
  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.
Lenguaje dominante
TypeScript
Estrellas
16.9k
Forks
1.3k
Merge medio
1 d 4 h
PR fusionados (30 d)
773

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de lidge-jun/opencodex

Todos los issues de lidge-jun/opencodex

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.