Lorsqu’un bot Telegram NanoClaw cesse de répondre, la première action n’est pas une correction — c’est de déterminer si les messages entrants atteignent l’hôte, car deux défaillances NanoClaw signalées séparément produisent cette plainte avec des signatures opposées. Dans l’une, les messages entrants cessent tandis que la livraison sortante et les tâches planifiées continuent de fonctionner ; toutes les surfaces vérifiées par l’opérateur semblent donc saines. Dans l’autre, rien ne part non plus et le journal marque comme livrés des messages qui ne l’ont jamais été. Même plainte, causes différentes, et le remède de l’une ne fait rien pour l’autre.
Une clarification du nom avant toute autre chose, car les résultats de recherche correspondant à cette expression concernent surtout un autre produit. OpenClaw est un projet distinct et bien plus vaste — 390,207 stars et une licence NOASSERTION lorsque sa fiche d’API de dépôt a été lue le 21 septembre 2026 — et la propre page d’accueil de NanoClaw se positionne face à lui. NanoClaw est nanocoai/nanoclaw : MIT, non archivé, pas un fork, 30,818 stars, 1,068 problèmes ouverts, dernier push le 19 septembre 2026 (API GitHub, même date). L’ancienne adresse qwibitai/nanoclaw renvoie par une redirection 301 vers celui-ci ; il s’agit donc du même projet renommé, pas d’un second projet. Les deux projets ne partagent aucun chemin de code Telegram — NanoClaw installe son propre adaptateur en copiant le code source depuis sa branche channels (skill add-telegram) — ; un remède OpenClaw ne s’applique donc pas. Pour la différence complète, consultez NanoClaw vs OpenClaw.
Lisez la signature avant de toucher à quoi que ce soit
Chaque ligne ci-dessous correspond à une défaillance distincte, signalée séparément, avec sa propre vérification de confirmation. Les huit cas ont été lus le 21 septembre 2026 dans le suivi des problèmes, les skills livrés et la documentation des canaux de NanoClaw.
| Ce que vous observez | Cause la plus probable | La vérification qui le confirme |
|---|---|---|
| Aucun message que vous envoyez ne reçoit de réponse, mais les réponses, les messages planifiés et la livraison sortante fonctionnent toujours | La boucle de polling échoue et réessaie indéfiniment — problème #3728, ouvert | Une ligne Telegram polling request failed contenant une valeur consecutiveFailures élevée ; les journaux de réussite n’affichent rien, donc un journal silencieux ne prouve pas que le service fonctionne |
Rien ne part non plus ; le journal principal affiche Message delivered avec platformMsgId=undefined à côté de No adapter for channel type | Deux instances hôtes simultanées — le second poller reçoit un 409 de Telegram, ce qui interrompt la configuration avant l’enregistrement de l’adaptateur (skill /debug, PR #2225) | L’absence d’une ligne Channel adapter started pour telegram, ainsi qu’un second processus dans ps aux |
| Les messages directs et les groupes fonctionnent ; les publications de canal n’arrivent jamais | Un filtre de mises à jour obsolète côté serveur sur le token du bot — problème #2989, ouvert | Ce token a-t-il déjà été utilisé par NanoClaw v1 ou une autre bibliothèque de bots ? La propre Bot API de Telegram indique à propos de allowed_updates : « If not specified, the previous setting will be used. » |
| Le bot répond aux messages directs, mais ignore les messages ordinaires des groupes | La confidentialité des groupes est activée (ajouter la compétence Telegram) | BotFather, /mybots, Paramètres du bot, Confidentialité des groupes — puis ajoutez de nouveau le bot au groupe |
| La messagerie fonctionne, mais l’association n’aboutit jamais | Le getMe au démarrage a échoué une fois et un nom d’utilisateur de bot nul est mis en cache pendant toute la durée de vie du processus — problème n° 3162, ouvert | Un avertissement Telegram getMe failed au démarrage, quelques minutes avant votre tentative d’association ; le problème indique qu’un redémarrage l’efface |
| La configuration s’interrompt avec « Impossible de joindre Telegram », ou le démarrage reste bloqué pendant environ une minute et demie | IPv6 configuré sans route fonctionnelle — problème n° 2377, ouvert | curl -4 vers l’API Bot réussit, tandis que curl -6 ne peut pas se connecter |
| La plupart des réponses arrivent, mais jamais celles qui contiennent certaines URL | Formatage sortant, pas réception : le problème n° 3569 signale que l’adaptateur épinglé tronque les messages contenant un nombre impair de marqueurs non échappés | Telegram rejette l’envoi ; deux URL contenant chacune un seul trait de soulignement s’annulent, ce qui donne l’impression que le problème est intermittent |
| Un deuxième bot que vous venez d’ajouter ne se met jamais en ligne | Les variables d’instance sont lues une seule fois au démarrage, et un jeton en double est ignoré (documentation du canal) | Un avertissement dans logs/nanoclaw.error.log (compétence Telegram) ; Telegram autorise un seul poller par jeton, donc chaque bot a besoin de son propre jeton BotFather |
Les diagnostics officiels de première ligne de NanoClaw sont deux fichiers journaux ainsi que ncl sessions list, ncl dropped-messages list et ncl wirings list. Aucune version publiée ne fournit de commande de vérification de l’activité du canal ; le triage ci-dessous s’appuie donc plutôt sur les lignes des journaux.
# 1. Is inbound polling failing, and for how long?
# A rising consecutiveFailures count is the #3728 signature.
grep "Telegram polling request failed" logs/nanoclaw.error.log | tail -5
# 2. Did the Telegram adapter ever register this boot?
# Its ABSENCE is the duplicate-host signature, not an error line.
grep "Channel adapter started" logs/nanoclaw.log | tail -10
# 3. Is a second host holding the polling session?
ps aux | grep 'nanoclaw/dist/index.js' | grep -v grep
systemctl --user list-units 'nanoclaw*' --all # Linux systemd installsPourquoi tout semble sain alors que les messages entrants sont bloqués
Le problème est structurel, et c’est la partie qui fait perdre le plus de temps. Le README de NanoClaw décrit le parcours suivant : application de messagerie vers le routeur de l’hôte, puis vers une base de données des messages entrants, dans le conteneur, vers une base de données des messages sortants, puis retour par le mécanisme de distribution. La distribution interroge indépendamment la base de données sortante, et une vérification de l’hôte toutes les 60 secondes réveille séparément les messages dus et récurrents. Les messages entrants sont la seule étape qui dépend du poller Telegram — c’est précisément pourquoi l’auteur du problème n° 3728 a vu l’hôte rester actif, la distribution sortante continuer à fonctionner et les tâches planifiées continuer à s’exécuter pendant environ quatre jours de silence total des messages entrants, avec 11 178 échecs consécutifs enregistrés.
Le hook de santé qui aurait dû le détecter ne le fait pas. La référence publiée de l’interface d’adaptateur de NanoClaw indique à propos de isConnected() qu’il n’est « actuellement pas appelé par l’hôte en dehors des tests » et que « le bridge renvoie toujours true ». Trunk a depuis évolué : une commande ncl status qui signale un indicateur de connexion par adaptateur a été intégrée à main le 15 septembre 2026, après la version v2.3.0, ce qui rend la documentation exacte pour toutes les versions publiées et obsolète pour trunk. Considérez cette commande comme un composant interne non publié plutôt que comme une recommandation — elle est enregistrée comme cachée et réservée à l’hôte, et n’apparaît dans aucune documentation. Pour Telegram, les deux chemins se rejoignent de toute façon : ni la version 4.29.0 ni la version 4.41.0 de l’adaptateur n’implémente isConnected (les deux builds dist ont été parcourus pour cette page), de sorte que la sonde revient à true dans les deux cas.
La documentation présente une lacune correspondante. La page de dépannage contient une section intitulée « Le canal webhook est silencieux », sans équivalent pour le polling, et son parcours « L’agent ne répond jamais » commence par « Le routeur l’a-t-il accepté ? » avec ncl dropped-messages list — une étape qui suppose déjà que le message a atteint l’hôte. Lorsque le poller est bloqué, il n’y a aucune ligne de message abandonné à rechercher, car le routeur n’a jamais vu le message. Le problème n° 2989 décrit la même impasse pour sa propre cause : aucune ligne de journal, aucune ligne de message abandonné, rien à déboguer.
Il n’existe aucune version corrective ; prévoyez donc une stratégie en conséquence
Le problème n° 3728 est ouvert, avec zéro commentaire, zéro libellé et aucun jalon, et son horodatage de mise à jour est toujours identique à son horodatage de création du 6 septembre 2026. La version la plus récente est v2.3.0, datée du 24 août 2026, et le seul commit de la branche channels depuis le 1er septembre concerne un correctif Mattermost. Il en va de même pour le cas du filtre obsolète : la pull request qui fixerait explicitement la liste des mises à jour est ouverte sur channels depuis le 22 août 2026, et le code source de la branche actuelle ne contient aucune occurrence de allowedUpdates. Le verrou de l’hôte à instance unique qui aurait empêché le cas des hôtes en double a été fermé sans être fusionné. La formulation honnête est donc une mesure d’atténuation, pas un numéro de version.
Trois choses méritent d’être connues avant d’écrire votre propre correctif. Premièrement, une modification locale de src/channels/telegram.ts ne persiste pas : la compétence add-telegram recopie ce fichier depuis la branche channels avec pour instruction de l’écraser, car cette branche fait autorité, et la compétence de mise à jour actualise chaque canal installé — c’est précisément ainsi que l’auteur du problème n° 3728 a perdu ce correctif à chaque mise à jour. Deuxièmement, le watchdog de l’auteur est autant un avertissement qu’une recette : la première version, fondée uniquement sur un compteur, a provoqué une panne de trois jours encore plus grave, car le poller s’est finalement arrêté au lieu d’échouer ; aucun nouvel échec n’a donc été enregistré et le compteur n’a jamais atteint son seuil. La deuxième version utilisait deux signaux indépendants et n’a jamais laissé le poller arrêté. Rien de tout cela n’est livré, approuvé ou vérifié indépendamment. Troisièmement, quel que soit votre développement, testez la récupération dans les deux sens : le succès sortant ne prouve rien concernant les messages entrants ; le contrôle pertinent est donc l’envoi d’un nouveau message depuis la conversation associée, qui produit une nouvelle ligne entrante.
Une défaillance du canal Telegram n’est pas un problème de modèle ou d’API
Il vaut la peine de le dire clairement, car la recherche évidente suivante envoie les utilisateurs dans la mauvaise direction. La documentation des identifiants de NanoClaw indique que les jetons de canal tels que TELEGRAM_BOT_TOKEN restent dans .env et sont utilisés par le processus de l’hôte, et non par les conteneurs, tandis que les identifiants de modèle résident dans le coffre-fort et sont injectés dans les requêtes sortantes pendant leur exécution. Les messages entrants atteignent le routeur et la base de données des messages entrants de la session avant qu’un fournisseur soit choisi, puisque le fournisseur est résolu lors du démarrage du conteneur (documentation des fournisseurs d’agents). Aucune URL de base, aucune clé, aucune passerelle ni aucun changement de fournisseur ne répare une boucle de polling bloquée, un filtre de mise à jour obsolète, une collision de pollers, la confidentialité des groupes ou une route IPv6 défaillante.
Le véritable point de croisement fonctionne dans l’autre sens. Le README de NanoClaw cite Claude Code parmi ses exigences, spécifiquement pour /customize, /debug et chaque compétence /add-channel ; il est donc nécessaire sur l’hôte pour réparer un canal, même si vos groupes d’agents s’exécutent sur autre chose. Les exigences de l’hôte sont macOS ou Linux, Windows via WSL2, Node.js 22 ou version ultérieure, pnpm 10 ou version ultérieure, et Docker — notez toutefois que nanoclaw.dev annonce toujours Node.js 20 ou version ultérieure, tandis que le README et le journal des modifications de v2.3.0 font de la version 22 un minimum strict. Fiez-vous au journal des modifications, qui qualifie cette hausse de rupture.
Ce que NanoClaw et son canal Telegram coûtent réellement
| Poste | Ce que cela coûte | Source |
|---|---|---|
| NanoClaw lui-même | 0 $, sous licence MIT, sans offre payante ni compte utilisateur | nanoclaw.dev : « NanoClaw est gratuit et open source sous licence MIT. » |
| Le compte du portail communautaire | Gratuit et facultatif ; tout le reste fonctionne sans lui | Le README du projet |
| Le jeton du bot Telegram | 0 $ pour le créer dans BotFather, et rien à acheter pour une conversation associée — l’offre facultative Paid Broadcasts de Telegram ne s’applique qu’au-delà de 30 messages par seconde | API Bot Telegram ; le mode polling signifie également qu’il n’y a ni URL publique, ni webhook, ni port ouvert, conformément à la documentation du canal |
| Utilisation des modèles | Le montant facturé par le fournisseur associé ; NanoClaw lui-même ne facture rien à ce titre | FAQ de nanoclaw.dev : « Le fournisseur de votre agent peut facturer l’utilisation des modèles. » |
| Docker | Requis sur l’hôte ; les conditions d’abonnement propres à Docker s’appliquent au-delà de ses seuils d’utilisation gratuite | Non vérifié pour cette page — consultez la page des tarifs de Docker avant d’établir votre budget |
Il n’existe aucune offre payante permettant de résoudre l’absence de réponse d’un bot, ce que ce tableau met utilement en évidence. Les dépenses ne commencent qu’une fois le canal à nouveau opérationnel et l’agent en train de répondre. Les chiffres ci-dessous sont une arithmétique illustrative de jetons, et non des coûts de tâches mesurés ni un plafond de facturation : supposons une conversation associée avec 25 tours par jour, 20 000 jetons d’entrée non mis en cache et 900 jetons de sortie par tour, sur 30 jours. Les tarifs sont les prix actuels du catalogue Kunavo par million de jetons.
| Modèle | Entrée / sortie par million | Mois estimé |
|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $12.86 |
| GPT-5.6 Terra | $0.70 / $4.20 | $13.34 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $38.59 |
| Claude Opus 5 | $3.50 / $17.50 | $64.31 |
Multipliez ce montant par votre propre trafic avant de le considérer comme un budget, et notez l’hypothèse qui pèse le plus : rien n’est servi depuis le cache. Une session d’agent de longue durée renvoie le contexte ; le comportement du cache modifie donc davantage ce nombre que l’écart de prix par jeton entre deux modèles voisins. Le montant du catalogue Kunavo constitue un plancher de facturation, et non un plafond : lorsque le fournisseur amont communique son coût, la facture correspond au plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Le rechargement minimal est de $10 de crédit prépayé, un minimum de financement et non des frais de tâche ou un abonnement ; consultez les détails de facturation.
| Route du modèle de l’agent | À privilégier lorsque | Ce que cela ne fait pas |
|---|---|---|
| API directe du fournisseur | Vous restez chez le modèle phare d’un fournisseur et souhaitez bénéficier de ses propres conditions de mise en cache et de traitement par lots | Un deuxième fournisseur implique un deuxième compte et un deuxième solde |
| Une passerelle compatible OpenAI ou compatible Anthropic | Vous changez de modèle par groupe d’agents et souhaitez une seule clé et un seul solde | Le fournisseur natif de NanoClaw est le Claude Agent SDK ; une URL de base personnalisée doit donc parler ce format filaire. Un point de terminaison au format OpenAI est atteint via la compétence de fournisseur OpenCode, qui achemine les modèles via sa propre configuration OpenCode |
| Un abonnement | Une utilisation quotidienne intensive à tarif fixe vous convient mieux que des jetons facturés à l’usage | NanoClaw ne vend aucun abonnement ; le forfait appartient au fournisseur |
| Un modèle local | Des tâches modestes ou privées sans facture de modèle hébergé | La propre compétence Ollama de NanoClaw est décrite comme visant un ancien chemin de configuration et non comme un remplacement direct pris en charge sur main actuellement |
Aucun de ces quatre choix ne touche au chemin Telegram. Pour le fonctionnement complet côté fournisseur — les deux variables d’environnement lues par la configuration, ce que voit réellement le conteneur, et la place d’OpenCode et de Codex — consultez Coûts et fournisseurs de l’API NanoClaw. Si vous connectez le runtime Claude par défaut à un point de terminaison personnalisé, le guide d’intégration Claude Code et la référence de l’URL de base couvrent la configuration, et vous pouvez créer un compte Kunavo lorsque vous êtes prêt à financer une clé. Kunavo n’a pas testé NanoClaw en conditions d’exécution ; un guide de configuration publié constitue une référence de configuration, pas un test de compatibilité.
Questions fréquentes
Pourquoi mon bot Telegram NanoClaw a-t-il cessé de répondre ?
Commencez par vérifier si les messages quittent toujours l’hôte. Si les réponses et les messages planifiés arrivent encore mais qu’aucun message que vous envoyez ne reçoit de réponse, le polling entrant est suspect : le problème NanoClaw #3728 indique que la boucle de polling de l’adaptateur réessaie getUpdates indéfiniment avec un plafond de backoff de 30 secondes, n’abandonne jamais et n’écrit rien lorsqu’un polling réussit, rendant l’échec invisible. Si rien ne part non plus et que le journal affiche des entrées « Message delivered » avec platformMsgId=undefined à côté d’avertissements « No adapter for channel type », le skill /debug de NanoClaw désigne comme cause l’exécution simultanée de deux instances du service. Ces deux cas ont des remèdes opposés ; identifiez donc la signature avant de modifier quoi que ce soit.
Existe-t-il une version corrigée du bug de polling Telegram de NanoClaw ?
Non, au 21 septembre 2026. Le problème #3728 est ouvert avec zéro commentaire, zéro étiquette et aucun jalon, et son horodatage de mise à jour correspond toujours à sa date de dépôt, le 6 septembre 2026. La version la plus récente de NanoClaw est v2.3.0, datée du 24 août 2026 ; rien n’est donc sorti depuis le signalement, et le seul commit de la branche channels depuis le 1er septembre est un correctif Mattermost. Quiconque vous conseille de passer à une version précise de NanoClaw pour résoudre ce problème cite une version qui n’existe pas.
La mise à niveau de @chat-adapter/telegram corrige-t-elle le problème ?
Pas le chemin de la mort silencieuse. NanoClaw épingle @chat-adapter/telegram exactement à 4.29.0, publiée le 18 mai 2026, tandis que la dernière balise dist d’npm est 4.41.0, datée du 18 septembre 2026. Les deux archives ont été téléchargées et comparées pour cette page : la branche d’échec de transport de getUpdates est matériellement identique dans les deux versions — même compteur consecutiveFailures, même plafond de backoff de 30 secondes, même ligne d’avertissement, aucun abandon ni escalade, et un polling réussi n’écrit toujours rien. La version 4.41.0 a réécrit d’autres parties de la boucle. Cette page présente cela comme un fait concernant le code et ne recommande pas de modifier l’épingle : le skill add-telegram de NanoClaw indique que la politique de chaîne d’approvisionnement refuse les plages, les deux pull requests de mise à niveau consultées pour cette page (#3460 et #3570) sont ouvertes et non fusionnées, et personne ici n’a testé ce que change d’autre une mise à niveau.
Changer de fournisseur d’API ou d’URL de base corrigera-t-il un problème Telegram ?
Non. La documentation des identifiants de NanoClaw indique que les tokens de canal comme TELEGRAM_BOT_TOKEN restent dans .env et sont utilisés par le processus hôte, pas par les conteneurs, tandis que les identifiants de modèle vont dans le coffre et sont injectés dans le trafic des conteneurs. Un message Telegram entrant atteint le routeur et la base de données entrante de la session avant qu’un fournisseur soit résolu, ce qui se produit au lancement du conteneur. Un endpoint, une clé ou une passerelle différente ne peut donc pas réparer une boucle de polling bloquée, un filtre de mises à jour obsolète côté serveur, une collision de pollers, Group Privacy ou une route IPv6 défaillante. Le seul croisement réel va dans l’autre sens : le README de NanoClaw indique Claude Code comme prérequis pour /debug et chaque skill /add-channel ; la réparation du canal en a donc besoin sur l’hôte, même si l’agent s’exécute ailleurs.
Le bot répond aux messages directs mais ignore le groupe. Pourquoi ?
Il s’agit généralement du paramètre Group Privacy de Telegram plutôt que d’un défaut de NanoClaw. Le skill add-telegram de NanoClaw indique qu’avec Group Privacy activé, le bot ne voit que les commandes et réponses qui lui sont adressées, pas le texte ordinaire, et qu’il faut le désactiver dans BotFather sous /mybots, votre bot, Bot Settings, Group Privacy — puis retirer et rajouter le bot au groupe pour que la modification prenne effet. Un autre cas lui ressemble mais est différent : le problème NanoClaw #2989 indique qu’un token de bot précédemment utilisé avec un filtre allowed_updates plus restrictif conserve ce filtre côté serveur indéfiniment, ce qui ignore silencieusement les publications de canal alors que les messages directs et les groupes continuent de fonctionner.
L’appariement ne se termine jamais, mais le bot fonctionne toujours. Quel est le problème ?
Le problème NanoClaw #3162 décrit exactement ce cas : si l’appel getMe au démarrage du canal échoue une fois, le nom d’utilisateur du bot est mis en cache comme null pendant toute la durée de vie du processus et chaque code d’appariement envoyé est traité comme un message ordinaire, sans tentative enregistrée, tandis que l’installateur attend indéfiniment. La seule trace est une ligne d’avertissement unique au démarrage, plusieurs minutes avant votre tentative d’appariement, et le problème indique qu’un redémarrage sans autre modification corrige le problème. L’adaptateur actuel de la branche channels effectue toujours cette recherche une seule fois, sans nouvelle tentative, et met le résultat en cache. Notez également que la documentation de NanoClaw décrit un code à 6 chiffres utilisable une fois, avec jusqu’à 5 codes régénérés par exécution, tandis que le problème #3162 parle d’un code à 4 chiffres ; fiez-vous à la documentation.
Vérifié le 21 septembre 2026 : la fiche du dépôt nanocoai/nanoclaw et la liste des versions, les états ouverts/fermés des problèmes n° 2377, 2989, 3162, 3569 et 3728 ainsi que des pull requests n° 2225, 2697, 3449, 3460 et 3570, le code source de l’adaptateur Telegram de la branche channels, les builds de l’adaptateur 4.29.0 épinglé et 4.41.0 actuel issus de npm, la documentation de NanoClaw consacrée aux canaux, aux identifiants, au dépannage et à l’interface d’adaptateur, ses compétences add-telegram et debug, ainsi que la page de l’API Bot de Telegram. Rien sur cette page n’a été exécuté contre une installation NanoClaw en fonctionnement. Les tarifs des jetons Kunavo proviennent du catalogue actuel, et les montants en dollars sont une arithmétique illustrative de jetons.