2026 OpenClaw : tâches sans réponse visible — openclaw doctor, heartbeat, thinking et logs (VNC Mac distant)
Les événements arrivent—Telegram, webhooks, cron—mais aucun texte d’assistant visible. Souvent un échec silencieux : heartbeat avec thinking, passerelle liée à 127.0.0.1, chemins de workflow fantômes dans le contexte, ou processus déjà arrêté pendant que vous regardez une vieille session. Cet article propose une séquence fixe : openclaw status → doctor → health → logs, puis heartbeat/thinking et parité du planificateur ; et comment ouvrir la console web dans une session VNC sur un Mac distant pour ne pas se fier au SSH seul.
Dix recettes d’erreurs : article dédié ; launchd : checklist daemon ; Docker : guide Compose. Ici : déclencheur présent, pas de réponse visible.
Trois auto-contrôles : le processus passerelle tourne-t-il encore ? Les jobs planifiés partagent-ils l’environnement et les flags modèle du shell interactif ? La console est-elle liée à l’interface que vous testez vraiment ? Si non—ne changez pas de modèle immédiatement.
1. Types de symptômes
- Canal vide : entrant ok, pas de texte sortant ; logs peuvent montrer un run sans sortie utilisateur.
- Planificateur muet seulement : chat interactif ok, cron/heartbeat silencieux—thinking, modèle heartbeat ou environnement différent.
- Fausse panne : curl local ok, pas à distance ; écoute loopback—navigateur en VNC clarifie vite.
Ces cas se chevauchent : un job journalise des runs pendant que thinking consomme les tokens visibles, et vous testez les ports depuis le mauvais hôte. Nommez le symptôme, puis suivez la chaîne de commandes.
2. Pourquoi le silence
- Thinking sans texte canal : le modèle travaille en interne ; les fenêtres heartbeat courtes semblent vides.
- Contexte pollué : ENOENT répété sur un fichier workflow halluciné.
- Fourche de config : shell interactif avec PATH/clés ; launchd ou Docker sans—
doctorpeut être vert ailleurs. - Liaison & pare-feu : console 18789 seulement localhost semble une panne totale depuis l’extérieur.
- Retries absorbés : UI « connectée », mais logs en backoff—lire les logs, pas seulement le voyant.
- Binaires multiples :
openclawshell ≠ binaire du daemon.
3. Matrice
| Ce que vous voyez | D’abord | Ensuite |
|---|---|---|
| Manuel OK, cron muet | modèle heartbeat + thinking | env launchd/cron vs shell |
| Toujours muet | openclaw status | doctor + health --json |
| Logs : run, pas de réponse | chemin outbound / sortie modèle | thinking long sans flush |
| Pas de console | liaison + pare-feu | navigateur en VNC |
| Parfois du texte, souvent vide | limitation / retries dans les logs | timeouts + étapes thinking |
La matrice oriente le premier regard, pas la taxonomie complète. En cas de doute, revenir à status → doctor → health → logs.
4. Sept étapes
openclaw status
Processus sous le bon utilisateur ? Recharger launchd après plist.
openclaw doctor
Capturer dépendances et permissions une fois pour le ticket.
openclaw health --json
Comparer deux exécutions pour dériver les endpoints.
openclaw logs --follow
Repro avec tail ; horodatages avant Ctrl+C.
heartbeat/cron thinking
Couper selon doc, retester le chemin planifié.
Workflow fantôme
Réinitialiser le contexte ou corriger la config si boucles ENOENT.
Console navigateur en VNC
Recouper loopback vs LAN/tunnel ; ports avec les posts Docker/launchd.
Modèle de ticket minimal
Cinq champs : (1) déclencheur (manuel/cron/Telegram) ; (2) une ligne status ; (3) blocages doctor ? ; (4) versions passerelle/modèle depuis health --json ; (5) ~30 lignes de logs horodatées. Cela rend les bugs « silencieux » bissectables.
5. Repères
- Sorties doctor+health sauvegardées ?
- heartbeat partage la config du chat ?
- Liaison 0.0.0.0 vs 127.0.0.1 vérifiée ?
- Logs horodatés pendant la repro ?
6. FAQ & conclusion
Vs article 10 erreurs ? Là, erreurs explicites ; ici silence et ordre des commandes.
Docker ? Mêmes commandes dans le conteneur ; ports selon le guide Docker, tests depuis hôte/VNC.
VM sans GUI vs Mac VNC ? Les démons tournent sans tête, mais callbacks locaux ou clics navigateur bloquent sans session graphique. Louer un Mac avec VNC achète l’observabilité.
Conclusion
Pas de réponse visible ⇒ souvent config, processus, thinking, liaison—rarement un modèle « cassé ». Si vous êtes sur Windows/Linux mais devez héberger sur macOS réel, un Mac distant accessible en VNC regroupe doctor, logs et navigateur. VNCMac et la série OpenClaw transforment le silence en tickets reproductibles.
Si tout semble vide : outbound réellement absent, ou thinking/formatage l’a mangé ? Les logs tranchent en secondes et évitent de tourner les clés API au hasard.