Dépannage

Cette page est le runbook approfondi. Commencez par /help/troubleshooting si vous voulez d’abord le flux de triage rapide.

Échelle de commandes

Exécutez-les d’abord, dans cet ordre :

openclaw statusopenclaw gateway statusopenclaw logs --followopenclaw doctoropenclaw channels status --probe

Signaux attendus en bon état :

• openclaw gateway status affiche Runtime: running, Connectivity probe: ok et une ligne Capability: ....
• openclaw doctor ne signale aucun problème bloquant de configuration ou de service.
• openclaw channels status --probe affiche l’état de transport en direct par compte et, lorsque c’est pris en charge, les résultats de sonde/audit tels que works ou audit ok.

Après une mise à jour

Utilisez ceci lorsqu’une mise à jour se termine mais que le Gateway est arrêté, que les canaux sont vides ou que les appels de modèle commencent à échouer avec des 401.

openclaw status --allopenclaw update status --jsonopenclaw gateway status --deepopenclaw doctor --fixopenclaw gateway restart

Recherchez :

• Update restart dans openclaw status / openclaw status --all. Les transferts en attente ou échoués incluent la prochaine commande à exécuter.
• plugin load failed: dependency tree corrupted; run openclaw doctor --fix sous Canaux. Cela signifie que la configuration du canal existe toujours, mais que l’enregistrement du Plugin a échoué avant que le canal puisse se charger.
• Des 401 de fournisseur après une nouvelle authentification. openclaw doctor --fix vérifie les anciennes copies d’auth OAuth par agent et les supprime afin que tous les agents résolvent le profil partagé actuel.

Installations split brain et garde de configuration plus récente

Utilisez ceci lorsqu’un service de gateway s’arrête de manière inattendue après une mise à jour, ou lorsque les journaux indiquent qu’un binaire openclaw est plus ancien que la version qui a écrit openclaw.json en dernier.

OpenClaw marque les écritures de configuration avec meta.lastTouchedVersion. Les commandes en lecture seule peuvent toujours inspecter une configuration écrite par un OpenClaw plus récent, mais les mutations de processus et de service refusent de continuer depuis un binaire plus ancien. Les actions bloquées incluent le démarrage, l’arrêt, le redémarrage, la désinstallation du service gateway, la réinstallation forcée du service, le démarrage du gateway en mode service et le nettoyage de port gateway --force.

which openclawopenclaw --versionopenclaw gateway status --deepopenclaw config get meta.lastTouchedVersion

openclaw gateway install --forceopenclaw gateway restart

Incompatibilité de protocole après rollback

Utilisez ceci lorsque les journaux continuent d’afficher protocol mismatch après une rétrogradation ou un retour arrière d’OpenClaw. Cela signifie qu’un ancien Gateway est en cours d’exécution, mais qu’un processus client local plus récent tente encore de se reconnecter avec une plage de protocoles que l’ancien Gateway ne sait pas gérer.

openclaw --versionwhich -a openclawopenclaw gateway status --deepopenclaw doctor --deepopenclaw logs --follow

Recherchez :

• protocol mismatch ... client=... v<version> min=<n> max=<n> expected=<n> dans les journaux du Gateway.
• Established clients: dans openclaw gateway status --deep ou Gateway clients dans openclaw doctor --deep. Cela liste les clients TCP actifs connectés au port du Gateway, y compris les PID et les lignes de commande lorsque le système d’exploitation le permet.
• Un processus client dont la ligne de commande pointe vers l’installation ou le wrapper OpenClaw plus récent depuis lequel vous avez effectué le rollback.

Correction :

1. Arrêtez ou redémarrez le processus client OpenClaw obsolète indiqué par gateway status --deep.
2. Redémarrez les applications ou wrappers qui intègrent OpenClaw, comme les tableaux de bord locaux, les éditeurs, les assistants de serveur d’application ou les shells openclaw logs --follow de longue durée.
3. Relancez openclaw gateway status --deep ou openclaw doctor --deep et confirmez que le PID client obsolète a disparu.

Ne faites pas accepter à un ancien Gateway un protocole plus récent incompatible. Les montées de version du protocole protègent le contrat filaire ; la récupération après rollback est un problème de nettoyage de processus/version.

Lien symbolique de Skill ignoré comme échappement de chemin

Utilisez ceci lorsque les journaux incluent :

Skipping escaped skill path outside its configured root: ... reason=symlink-escape

OpenClaw traite chaque racine de skill comme une frontière de confinement. Un lien symbolique sous ~/.agents/skills, <workspace>/.agents/skills, <workspace>/skills ou ~/.openclaw/skills est ignoré lorsque sa cible réelle se résout en dehors de cette racine, sauf si la cible est explicitement approuvée.

Inspectez le lien :

ls -l ~/.agents/skills/<name>realpath ~/.agents/skills/<name>openclaw config get skills.load

Si la cible est intentionnelle, configurez à la fois la racine directe du skill et la cible de lien symbolique autorisée :

{  skills: {    load: {      extraDirs: ["~/Projects/manager/skills"],      allowSymlinkTargets: ["~/Projects/manager/skills"],    },  },}

Démarrez ensuite une nouvelle session ou attendez que l’observateur de Skills se rafraîchisse. Redémarrez le gateway si le processus en cours est antérieur au changement de configuration.

N’utilisez pas de cibles larges comme ~, / ou un dossier de projet synchronisé entier. Gardez allowSymlinkTargets limité à la racine réelle de skills qui contient les répertoires SKILL.md approuvés.

Si Skill Workshop apply doit aussi écrire via ces chemins de skills d’espace de travail liés symboliquement et approuvés, activez skills.workshop.allowSymlinkTargetWrites. Gardez-le désactivé pour les racines de skills partagées en lecture seule.

Liens connexes :

• Configuration des Skills
• Exemples de configuration

Utilisation supplémentaire Anthropic 429 requise pour un contexte long

Utilisez ceci lorsque les journaux/erreurs incluent : HTTP 429: rate_limit_error: Extra usage is required for long context requests.

openclaw logs --followopenclaw models statusopenclaw config get agents.defaults.models

Recherchez :

• Le modèle Anthropic sélectionné est un modèle Claude 4.x 1M compatible GA, ou le modèle a l’ancien params.context1m: true.
• L’identifiant Anthropic actuel n’est pas éligible à l’utilisation de contexte long.
• Les requêtes échouent uniquement sur les longues sessions/exécutions de modèle qui nécessitent le chemin de contexte 1M.

Options de correction :

Liens connexes :

• Anthropic
• Utilisation des tokens et coûts
• Pourquoi vois-je HTTP 429 depuis Anthropic ?

Réponses 403 bloquées en amont

Utilisez ceci lorsqu’un fournisseur LLM en amont renvoie un 403 générique tel que Your request was blocked.

Ne supposez pas qu’il s’agit toujours d’un problème de configuration OpenClaw. La réponse peut provenir d’une couche de sécurité en amont comme un CDN, un WAF, une règle de gestion des bots ou un proxy inverse devant un endpoint compatible OpenAI.

openclaw statusopenclaw gateway statusopenclaw logs --follow

Recherchez :

• plusieurs modèles sous le même fournisseur échouant de la même manière
• du HTML ou un texte de sécurité générique au lieu d’une erreur normale d’API fournisseur
• des événements de sécurité côté fournisseur au même moment que la requête
• une minuscule sonde directe curl qui réussit alors que les requêtes normales de forme SDK échouent

Corrigez d’abord le filtrage côté fournisseur lorsque les éléments indiquent un blocage WAF/CDN. Préférez une règle d’autorisation ou d’exclusion à portée étroite pour le chemin d’API qu’OpenClaw utilise, et évitez de désactiver la protection pour tout le site.

Liens connexes :

• Endpoints compatibles OpenAI
• Configuration des fournisseurs
• Journaux

Le backend local compatible OpenAI réussit les sondes directes mais les exécutions d’agent échouent

Utilisez ceci lorsque :

• curl ... /v1/models fonctionne
• de minuscules appels directs /v1/chat/completions fonctionnent
• les exécutions de modèle OpenClaw échouent uniquement lors de tours d’agent normaux

curl http://127.0.0.1:1234/v1/modelscurl http://127.0.0.1:1234/v1/chat/completions \  -H 'content-type: application/json' \  -d '{"model":"<id>","messages":[{"role":"user","content":"hi"}],"stream":false}'openclaw infer model run --model <provider/model> --prompt "hi" --jsonopenclaw logs --follow

Recherchez :

• les minuscules appels directs réussissent, mais les exécutions OpenClaw échouent uniquement sur des prompts plus grands
• des erreurs model_not_found ou 404 alors que l’appel direct /v1/chat/completions fonctionne avec le même identifiant de modèle nu
• des erreurs backend indiquant que messages[].content attend une chaîne
• des avertissements intermittents incomplete turn detected ... stopReason=stop payloads=0 avec un backend local compatible OpenAI
• des plantages backend qui apparaissent uniquement avec des nombres de tokens de prompt plus élevés ou des prompts complets du runtime d’agent

Liens connexes :

• Configuration
• Modèles locaux
• Points de terminaison compatibles OpenAI

Aucune réponse

Si les canaux sont actifs mais que rien ne répond, vérifiez le routage et la politique avant de reconnecter quoi que ce soit.

openclaw statusopenclaw channels status --probeopenclaw pairing list --channel <channel> [--account <id>]openclaw config get channelsopenclaw logs --follow

Recherchez :

• Appairage en attente pour les expéditeurs de messages privés.
• Filtrage des mentions de groupe (requireMention, mentionPatterns).
• Incompatibilités de liste d’autorisation de canal/groupe.

Signatures courantes :

• drop guild message (mention required → message de groupe ignoré jusqu’à mention.
• pairing request → l’expéditeur doit être approuvé.
• blocked / allowlist → l’expéditeur/le canal a été filtré par la politique.

Connexe :

• Dépannage des canaux
• Groupes
• Appairage

Connectivité de l’interface de contrôle du tableau de bord

Lorsque le tableau de bord/l’interface de contrôle ne se connecte pas, validez l’URL, le mode d’authentification et les hypothèses de contexte sécurisé.

openclaw gateway statusopenclaw statusopenclaw logs --followopenclaw doctoropenclaw gateway status --json

Recherchez :

• URL de sonde et URL du tableau de bord correctes.
• Incompatibilité de mode d’authentification/jeton entre le client et le Gateway.
• Utilisation de HTTP quand l’identité de l’appareil est requise.

Si un navigateur local ne peut pas se connecter à 127.0.0.1:18789 après une mise à jour, commencez par rétablir le service Gateway local et confirmez qu’il sert le tableau de bord :

openclaw gateway restartlsof -i :18789curl http://127.0.0.1:18789

Si curl renvoie du HTML OpenClaw, le Gateway fonctionne et le problème restant est probablement le cache du navigateur, un ancien lien profond ou un état d’onglet obsolète. Ouvrez http://127.0.0.1:18789 directement et naviguez depuis le tableau de bord. Si le redémarrage ne laisse pas le service en cours d’exécution, exécutez openclaw gateway start et revérifiez openclaw gateway status.

Carte rapide des codes de détail d’authentification

Utilisez error.details.code de la réponse connect échouée pour choisir l’action suivante :

Vérification de migration de l’authentification d’appareil v2 :

openclaw --versionopenclaw doctoropenclaw gateway status

Si les journaux affichent des erreurs de nonce/signature, mettez à jour le client qui se connecte et vérifiez-le :

Si openclaw devices rotate / revoke / remove est refusé de manière inattendue :

• les sessions de jeton d’appareil appairé ne peuvent gérer que leur propre appareil, sauf si l’appelant dispose aussi de operator.admin
• openclaw devices rotate --scope ... ne peut demander que les portées d’opérateur que la session appelante possède déjà

Connexe :

• Configuration (modes d’authentification Gateway)
• Interface de contrôle
• Appareils
• Accès à distance
• Authentification par proxy de confiance

Service Gateway non exécuté

Utilisez ceci lorsque le service est installé mais que le processus ne reste pas actif.

openclaw gateway statusopenclaw statusopenclaw logs --followopenclaw doctoropenclaw gateway status --deep   # also scan system-level services

Recherchez :

• Runtime: stopped avec des indices de sortie.
• Incompatibilité de configuration du service (Config (cli) contre Config (service)).
• Conflits de port/écouteur.
• Installations launchd/systemd/schtasks supplémentaires lorsque --deep est utilisé.
• Indices de nettoyage Other gateway-like services detected (best effort).

Connexe :

• Exécution en arrière-plan et outil de processus
• Configuration
• Doctor

Le Gateway macOS cesse silencieusement de répondre, puis reprend lorsque vous touchez le tableau de bord

Utilisez ceci lorsque les canaux (Telegram, WhatsApp, etc.) sur un hôte macOS deviennent silencieux pendant des minutes ou des heures à la fois, et que le Gateway semble revenir au moment où vous ouvrez l’interface de contrôle, vous connectez en SSH ou interagissez autrement avec l’hôte. Il n’y a généralement aucun symptôme évident dans openclaw status, car au moment où vous regardez, le Gateway est de nouveau actif.

ls ~/.openclaw/logs/stability/ | tail -5openclaw gateway stability --bundle latestpmset -g log | grep -iE "sleep|wake|maintenance" | tail -50launchctl print gui/$UID/ai.openclaw.gateway | grep -E "state|last exit|runs"

Recherchez :

• Un ou plusieurs bundles *-uncaught_exception.json dans ~/.openclaw/logs/stability/ avec error.code défini sur un code réseau transitoire comme ENETDOWN, ENETUNREACH, EHOSTUNREACH ou ECONNREFUSED.
• Des lignes pmset -g log comme Entering Sleep state due to 'Maintenance Sleep' ou en0 driver is slow (msg: WillChangeState to 0) alignées avec les horodatages des plantages. Power Nap / Maintenance Sleep place brièvement le pilote Wi-Fi dans l’état 0 ; tout connect() sortant qui tombe dans cette fenêtre peut échouer avec ENETDOWN, même sur un hôte qui dispose par ailleurs d’une connectivité réseau complète.
• Une sortie launchctl print affichant state = not running avec plusieurs runs récents et un code de sortie, surtout lorsque l’écart entre le plantage et le lancement suivant est de l’ordre d’une heure plutôt que de quelques secondes. Sur macOS, launchd applique une barrière non documentée de protection contre les redémarrages après une rafale de plantages, qui peut cesser d’honorer KeepAlive=true jusqu’à ce qu’un déclencheur externe comme une connexion interactive, une connexion au tableau de bord ou launchctl kickstart la réarme.

Signatures courantes :

• Un bundle de stabilité dont error.code est ENETDOWN ou un code apparenté, avec une pile d’appels pointant vers Node net lookupAndConnect / Socket.connect. OpenClaw 2026.5.26 et les versions plus récentes classent ces erreurs comme des erreurs réseau transitoires bénignes, afin qu’elles ne se propagent plus jusqu’au gestionnaire global d’exceptions non interceptées ; si vous utilisez une version plus ancienne, mettez d’abord à niveau.
• De longues périodes silencieuses qui prennent fin à l’instant où vous vous connectez à l’interface de contrôle ou en SSH à l’hôte : l’activité visible par l’utilisateur est ce qui réarme la barrière de redémarrage de launchd, pas une action du tableau de bord sur le Gateway.
• Le compteur runs augmente au cours de la journée sans ligne correspondante received SIG*; shutting down dans ~/Library/Logs/openclaw/gateway.log : les arrêts propres journalisent un signal ; les plantages transitoires ne le font pas.

Que faire :

1. Mettez à niveau le Gateway si vous exécutez une version antérieure à 2026.5.26. Après la mise à niveau, les futures erreurs ENETDOWN seront journalisées comme des avertissements au lieu de terminer le processus.

2. Réduisez l’activité de veille de maintenance sur les hôtes Mac mini / de bureau destinés à fonctionner comme serveurs toujours actifs :

   sudo pmset -a sleep 0 disksleep 0 standby 0 powernap 0

   Cela réduit fortement, sans l’éliminer entièrement, l’instabilité sous-jacente du pilote. Le système peut toujours effectuer certaines veilles de maintenance pour l’entretien TCP keepalive et mDNS, indépendamment de ces options.

3. Ajoutez un watchdog de disponibilité afin qu’une future rafale de plantages immobilisée par launchd soit détectée rapidement :

   # Example launchd-aware liveness check, suitable for a 5-minute cron or LaunchAgentstate=$(launchctl print gui/$UID/ai.openclaw.gateway 2>/dev/null | awk -F'= ' '/state =/ {print $2; exit}')if [ "$state" != "running" ]; then  launchctl kickstart -k gui/$UID/ai.openclaw.gatewayfi

   L’objectif est de réarmer de l’extérieur la barrière de redémarrage ; KeepAlive=true seul ne suffit pas sur macOS après une rafale de plantages.

Associé :

• Notes de plateforme macOS
• Journalisation
• Doctor

Le Gateway se ferme lors d’une forte utilisation mémoire

Utilisez ceci lorsque le Gateway disparaît sous charge, que le superviseur signale un redémarrage de type OOM, ou que les journaux mentionnent critical memory pressure bundle written.

openclaw gateway status --deepopenclaw logs --followopenclaw gateway stability --bundle latestopenclaw gateway diagnostics export

Recherchez :

• Reason: diagnostic.memory.pressure.critical dans le dernier bundle de stabilité.
• Memory pressure: avec critical/rss_threshold, critical/heap_threshold ou critical/rss_growth.
• Des valeurs V8 heap: proches de la limite du tas.
• Des entrées Largest session files: comme agents/<agent>/sessions/<session>.jsonl ou sessions/<session>.jsonl.
• Des compteurs mémoire cgroup Linux lorsque le Gateway s’exécute dans un conteneur ou un service à mémoire limitée.

Signatures courantes :

• critical memory pressure bundle written apparaît peu avant le redémarrage → OpenClaw a capturé un bundle de stabilité pré-OOM. Inspectez-le avec openclaw gateway stability --bundle latest.
• memory pressure: level=critical ... memoryPressureSnapshot=disabled apparaît dans les journaux du Gateway → OpenClaw a détecté une pression mémoire critique, mais l’instantané de stabilité pré-OOM est désactivé.
• Largest session files: pointe vers un très grand chemin de transcription expurgée → réduisez l’historique de session conservé, inspectez la croissance de la session, ou déplacez les anciennes transcriptions hors du magasin actif avant de redémarrer.
• Les octets utilisés V8 heap: sont proches de la limite du tas → réduisez la pression des prompts/sessions, réduisez le travail concurrent, ou augmentez la limite du tas Node seulement après avoir confirmé que la charge de travail est attendue.
• Memory pressure: critical/rss_growth → la mémoire a augmenté rapidement dans une même fenêtre d’échantillonnage. Vérifiez les derniers journaux pour une importation volumineuse, une sortie d’outil incontrôlée, des tentatives répétées, ou un lot de travaux d’agent en file d’attente.
• Une pression mémoire critique apparaît dans les journaux mais aucun bundle n’existe → c’est le comportement par défaut. Définissez diagnostics.memoryPressureSnapshot: true pour capturer le bundle de stabilité pré-OOM lors des futurs événements de pression mémoire critique.

Le bundle de stabilité ne contient aucune charge utile. Il inclut des preuves opérationnelles de mémoire et des chemins de fichiers relatifs expurgés, pas le texte des messages, les corps de webhook, les identifiants, les jetons, les cookies ni les identifiants de session bruts. Joignez l’export de diagnostics aux rapports de bug au lieu de copier les journaux bruts.

Associé :

• Santé du Gateway
• Export de diagnostics
• Sessions

Le Gateway a rejeté une config invalide

Utilisez ceci lorsque le démarrage du Gateway échoue avec Invalid config ou que les journaux de rechargement à chaud indiquent qu’il a ignoré une modification invalide.

openclaw logs --followopenclaw config fileopenclaw config validateopenclaw doctor

Recherchez :

• Invalid config at ...
• config reload skipped (invalid config): ...
• Config write rejected: ...
• Un fichier horodaté openclaw.json.rejected.* à côté de la config active
• Un fichier horodaté openclaw.json.clobbered.* si doctor --fix a réparé une modification directe cassée
• OpenClaw conserve les 32 derniers fichiers .clobbered.* pour chaque chemin de config et applique une rotation aux plus anciens

CONFIG="$(openclaw config file)"ls -lt "$CONFIG".clobbered.* "$CONFIG".rejected.* 2>/dev/null | headdiff -u "$CONFIG" "$(ls -t "$CONFIG".clobbered.* 2>/dev/null | head -n 1)"openclaw config validateopenclaw doctor

Associé :

• Config
• Configuration : rechargement à chaud
• Configuration : validation stricte
• Doctor

Avertissements de sonde du Gateway

Utilisez ceci lorsque openclaw gateway probe atteint quelque chose, mais affiche tout de même un bloc d’avertissement.

openclaw gateway probeopenclaw gateway probe --jsonopenclaw gateway probe --ssh user@gateway-host

Recherchez :

• warnings[].code et primaryTargetId dans la sortie JSON.
• Si l’avertissement concerne le repli SSH, plusieurs gateways, des portées manquantes, ou des références d’authentification non résolues.

Signatures courantes :

• SSH tunnel failed to start; falling back to direct probes. → la configuration SSH a échoué, mais la commande a tout de même essayé les cibles directes configurées/local loopback.
• multiple reachable gateway identities detected → des gateways distincts ont répondu, ou OpenClaw n’a pas pu prouver que les cibles atteignables sont le même gateway. Un tunnel SSH, une URL proxy, ou une URL distante configurée vers le même gateway est traité comme un gateway unique avec plusieurs transports, même lorsque les ports de transport diffèrent.
• Read-probe diagnostics are limited by gateway scopes (missing operator.read) → la connexion a fonctionné, mais le RPC de détail est limité par la portée ; associez l’identité de l’appareil ou utilisez des identifiants avec operator.read.
• Gateway accepted the WebSocket connection, but follow-up read diagnostics failed → la connexion a fonctionné, mais l’ensemble complet de RPC de diagnostic a expiré ou échoué. Traitez cela comme un Gateway atteignable avec des diagnostics dégradés ; comparez connect.ok et connect.rpcOk dans la sortie --json.
• Capability: pairing-pending ou gateway closed (1008): pairing required → le gateway a répondu, mais ce client nécessite encore un appairage/une approbation avant l’accès opérateur normal.
• Texte d’avertissement SecretRef gateway.auth.* / gateway.remote.* non résolu → le matériel d’authentification n’était pas disponible dans ce chemin de commande pour la cible en échec.

Associé :

• Gateway
• Plusieurs gateways sur le même hôte
• Accès distant

Canal connecté, messages bloqués

Si l’état du canal est connecté mais que le flux de messages est interrompu, concentrez-vous sur la politique, les permissions et les règles de livraison propres au canal.

openclaw channels status --probeopenclaw pairing list --channel <channel> [--account <id>]openclaw status --deepopenclaw logs --followopenclaw config get channels

Recherchez :

• La politique de messages privés (pairing, allowlist, open, disabled).
• La liste d’autorisation de groupe et les exigences de mention.
• Les permissions/portées d’API de canal manquantes.

Signatures courantes :

• mention required → message ignoré par la politique de mention de groupe.
• Traces pairing / d’approbation en attente → l’expéditeur n’est pas approuvé.
• missing_scope, not_in_channel, Forbidden, 401/403 → problème d’authentification/permissions du canal.

Associé :

• Dépannage des canaux
• Discord
• Telegram
• WhatsApp

Livraison Cron et Heartbeat

Si cron ou heartbeat ne s’est pas exécuté ou n’a pas livré, vérifiez d’abord l’état du planificateur, puis la cible de livraison.

openclaw cron statusopenclaw cron listopenclaw cron runs --id <jobId> --limit 20openclaw system heartbeat lastopenclaw logs --follow

Recherchez :

• Cron activé et prochain réveil présent.
• État de l’historique d’exécution des tâches (ok, skipped, error).
• Raisons de saut du Heartbeat (quiet-hours, requests-in-flight, cron-in-progress, lanes-busy, alerts-disabled, empty-heartbeat-file, no-tasks-due).

Associé :

• Heartbeat
• Tâches planifiées
• Tâches planifiées : dépannage

Node appairé, échec de l’outil

Si un Node est appairé mais que les outils échouent, isolez l’état de premier plan, des autorisations et des approbations.

openclaw nodes statusopenclaw nodes describe --node <idOrNameOrIp>openclaw approvals get --node <idOrNameOrIp>openclaw logs --followopenclaw status

Recherchez :

• Node en ligne avec les capacités attendues.
• Autorisations du système d’exploitation pour la caméra, le micro, la localisation et l’écran.
• Approbations d’exécution et état de la liste d’autorisation.

Signatures courantes :

• NODE_BACKGROUND_UNAVAILABLE → l’application du Node doit être au premier plan.
• *_PERMISSION_REQUIRED / LOCATION_PERMISSION_REQUIRED → autorisation du système d’exploitation manquante.
• SYSTEM_RUN_DENIED: approval required → approbation d’exécution en attente.
• SYSTEM_RUN_DENIED: allowlist miss → commande bloquée par la liste d’autorisation.

Associé :

• Approbations d’exécution
• Dépannage des Node
• Node

Échec de l’outil navigateur

Utilisez ceci lorsque les actions de l’outil navigateur échouent alors que le Gateway lui-même est sain.

openclaw browser statusopenclaw browser start --browser-profile openclawopenclaw browser profilesopenclaw logs --followopenclaw doctor

Recherchez :

• Si plugins.allow est défini et inclut browser.
• Chemin valide vers l’exécutable du navigateur.
• Accessibilité du profil CDP.
• Disponibilité de Chrome local pour les profils existing-session / user.

Associé :

• Navigateur (géré par OpenClaw)
• Dépannage du navigateur

Si vous avez effectué une mise à niveau et que quelque chose s’est soudainement cassé

La plupart des pannes après mise à niveau proviennent d’une dérive de configuration ou de valeurs par défaut plus strictes désormais appliquées.

openclaw gateway statusopenclaw config get gateway.modeopenclaw config get gateway.remote.urlopenclaw config get gateway.auth.mode

openclaw config get gateway.bindopenclaw config get gateway.auth.modeopenclaw config get gateway.auth.tokenopenclaw gateway statusopenclaw logs --follow

openclaw devices listopenclaw pairing list --channel <channel> [--account <id>]openclaw logs --followopenclaw doctor

Si la configuration du service et l’exécution divergent encore après les vérifications, réinstallez les métadonnées de service depuis le même répertoire de profil/état :

openclaw gateway install --forceopenclaw gateway restart

Associé :

• Authentification
• Exécution en arrière-plan et outil de processus
• Appairage détenu par le Gateway

Associé

• Doctor
• FAQ
• Runbook du Gateway