2026 OpenClaw — Dépannage auth production :
Unauthorized, tokens et clés API fournisseur — séparer les rôles

Passer d’OpenClaw « qui marche sur mon poste » à « auditable en production » coince souvent sur deux messages : Unauthorized et No API key for provider. Ils pointent vers la couche session Gateway et la couche secrets fournisseur modèle—correctifs et fichiers différents. Ce guide propose un ordre minimal 2026 (gateway statusdoctormodels auth), un runbook en six étapes, une matrice de symptômes et une checklist d’isolation des secrets. Avant la mise en prod, finissez d’abord l’article CVE-2026-25253 + baseline Node 24 production.

01

Six pièges « évidents » qui gaspillent des tickets

Chaque point reflète une fausse piste réelle du support—lisez avant de taper des commandes.

  • 01

    Traiter tout Unauthorized comme un token perdu : les proxies peuvent retirer des en-têtes ; le cache CLI peut garder un token vide ; le navigateur peut bloquer WebCrypto hors HTTPS.

  • 02

    Imputer à Gateway l’absence de clés fournisseur : souvent l’identité agent n’a jamais reçu models auth, ou les unités systemd utilisateur n’exportent pas les variables d’environnement.

  • 03

    Réinstaller avant doctor : masque un PATH dupliqué et une dérive de config—suivez d’abord la triade éditeur.

  • 04

    Copier les clés dev dans la CI : casse le moindre privilège et la rotation ; une identité par runner.

  • 05

    Ignorer 127.0.0.1 + Tailscale : la CLI distante résout tokens et DNS différemment—validez les deux côtés.

  • 06

    Sauter la validation disque : sans config:validate (ou équivalent), faux négatifs « commande OK mais le process ne lit pas ».

02

Vue partagée : Gateway vs fournisseur

SymptômeCouche à inspecterPremière commandeÉtape suivante
401 / Unauthorized (CLI ou WebSocket)Session Gatewayopenclaw gateway statusopenclaw doctor ; régénérer le token Gateway si besoin
Clé API manquante avant l’appel modèleSecrets fournisseuropenclaw models statusopenclaw models auth setup-token … avec le bon scope agent
Succès intermittentDouble identité / configwhich openclaw + env du service utilisateurAligner PATH et Environment= systemd
Échec seulement en CLI distanteTunnel / propagation du tokenRetester 127.0.0.1 en localVérifier Tailscale Serve et les exigences HTTPS

« Classer d’abord, corriger ensuite »—la même chaîne Unauthorized demande une autre chirurgie sur le chemin Gateway ou fournisseur.

03

Runbook production en six étapes

  1. 01

    Geler l’état : noter le texte d’erreur exact, l’heure, l’utilisateur / l’ID agent—éviter de changer token et clés fournisseur en même temps.

  2. 02

    Minimum Gateway :openclaw gateway statusopenclaw doctor ; régénérer le token selon la doc éditeur s’il manque.

  3. 03

    Valider sur disque : droits alignés sur l’utilisateur Gateway ; redémarrer le service utilisateur après modification.

  4. 04

    Passer sur la piste fournisseur :openclaw models status, puis models auth setup-token ; ne jamais coller de secrets dans un historique shell partagé.

  5. 05

    Isoler les secrets : matériel de clés par agent / environnement ou références gestionnaire de secrets ; interdire les répertoires world-readable en prod.

  6. 06

    Piste d’audit : consigner fenêtres de rotation, blast radius et points de rollback dans le ticket de changement.

bash
openclaw gateway status
openclaw doctor
openclaw models status
# openclaw models auth setup-token --provider anthropic  # compléter selon la doc officielle
info

Note : pour les services systemd utilisateur, injectez les variables fournisseur dans l’unité—pas seulement dans un shell interactif.

warning

Attention : ne collez jamais des tokens / clés API complets dans des tickets publics ; empreinte avec quatre premiers et quatre derniers caractères.

04

Trois formulations prêtes pour la revue (sans chiffres « secrets » éditeur)

  • Périmètre : OpenClaw Gateway impose la frontière session / outillage ; les clés API fournisseur suivent la rotation éditeur et votre processus de gestion des secrets.
  • Observabilité : scindez les métriques « auth failed » en compteurs Gateway vs fournisseur pour garder des alertes actionnables.
  • Runtime : les Gateways de prod exigent un Node stable, des droits fichiers prévisibles et des modèles de processus longue durée—pas comme un laptop de dev.

Faire tourner un Gateway sur un portable qui dort provoque des échecs d’auth intermittents (thermique, politique d’alimentation). Un nœud macOS dédié, toujours allumé convient mieux aux gateways agents de production. Pour une capacité Mac de type VPS avec maintenance SSH et images auditables, la location cloud Mac Mini NodeMini s’aligne souvent mieux avec nos guides mode distant et Tailscale.

FAQ

FAQ

Pas toujours—utilisez la section 2, puis gateway status et doctor. Autres sujets OpenClaw : filtre blog OpenClaw.

À éviter—séparez identités et rotations. Capacité : tarifs de location Mac mini.

Vérifiez d’abord PATH / binaire dupliqué et la dérive d’environnement systemd, puis relancez ce runbook. Aide : centre d’aide.