Quando un bot Telegram NanoClaw smette di rispondere, la prima mossa non è una correzione: è stabilire se i messaggi in ingresso raggiungono l’host, perché due guasti di NanoClaw segnalati separatamente producono quella lamentela con firme opposte. In un caso, l’ingresso muore mentre la consegna in uscita e le attività pianificate continuano a funzionare, quindi ogni superficie controllata dall’operatore appare sana. Nell’altro, non viene inviato nulla e il log contrassegna come consegnati messaggi che non sono mai stati inviati. Stessa lamentela, cause diverse, e un rimedio per uno non fa nulla per l’altro.
Un chiarimento prima di tutto, perché i risultati di ricerca per questa frase riguardano soprattutto un prodotto diverso. OpenClaw è un progetto distinto e molto più grande — 390.207 stelle e una licenza NOASSERTION quando il record API del repository è stato letto il 21 settembre 2026 — e la homepage di NanoClaw si posiziona rispetto a esso. NanoClaw è nanocoai/nanoclaw: MIT, non archiviato, non un fork, 30.818 stelle, 1.068 problemi aperti, ultimo push il 19 settembre 2026 (API GitHub, stessa data). Il vecchio indirizzo qwibitai/nanoclaw restituisce un 301 verso di esso, quindi è lo stesso progetto rinominato, non un secondo progetto. I due progetti non condividono alcun percorso di codice Telegram — NanoClaw installa il proprio adapter copiando il codice sorgente dal suo branch channels (skill add-telegram) — quindi una soluzione per OpenClaw non è trasferibile. Per la differenza completa, consulta NanoClaw vs OpenClaw.
Leggi la firma prima di toccare qualsiasi cosa
Ogni riga seguente è un guasto distinto, segnalato separatamente, con una propria verifica di conferma. Tutti gli otto casi sono stati letti il 21 settembre 2026 dal tracker dei problemi, dalle skill distribuite e dalla documentazione dei canali di NanoClaw.
| Cosa osservi | Causa più probabile | La verifica che lo conferma |
|---|---|---|
| Nulla di ciò che invii riceve risposta, ma le risposte, i messaggi pianificati e la consegna in uscita continuano a funzionare | Il ciclo di polling sta fallendo e ritentando per sempre — problema #3728, aperto | Una riga Telegram polling request failed che contiene un valore consecutiveFailures elevato; i log di successo non mostrano nulla, quindi un log silenzioso non è una prova di integrità |
Non viene inviato nulla; il log principale mostra Message delivered con platformMsgId=undefined accanto a No adapter for channel type | Due istanze host contemporaneamente — il secondo poller riceve un 409 da Telegram, che interrompe la configurazione prima che l’adapter venga registrato (skill /debug, PR #2225) | L’assenza di una riga Channel adapter started per telegram, oltre a un secondo processo in ps aux |
| I messaggi diretti e i gruppi funzionano; i post dei canali non arrivano mai | Un filtro degli aggiornamenti obsoleto lato server sul token del bot — problema #2989, aperto | Questo token era stato precedentemente sottoposto a polling da NanoClaw v1 o da un’altra libreria bot? La Bot API di Telegram afferma quanto segue riguardo a allowed_updates: "If not specified, the previous setting will be used." |
| Il bot risponde ai messaggi diretti, ma ignora i normali messaggi di gruppo | La privacy del gruppo è attiva (add-telegram skill) | BotFather, /mybots, Impostazioni del bot, Privacy del gruppo — quindi aggiungi nuovamente il bot al gruppo |
| La messaggistica funziona, ma l'associazione non viene mai completata | Il getMe all'avvio non è riuscito una volta e per tutta la durata del processo viene memorizzato un nome utente del bot nullo — issue #3162, aperta | Un avviso Telegram getMe failed all'avvio, pochi minuti prima del tentativo di associazione; l'issue segnala che un riavvio lo cancella |
| La configurazione si interrompe con "Couldn't reach Telegram", oppure l'avvio si blocca per circa un minuto e mezzo | IPv6 configurato senza una route funzionante — issue #2377, aperta | curl -4 verso la Bot API ha esito positivo, mentre curl -6 non riesce a connettersi |
| La maggior parte delle risposte arriva, ma quelle contenenti determinati URL non arrivano mai | Formattazione in uscita, non ricezione: issue #3569 segnala che l'adapter indicato tronca i messaggi con un numero dispari di marker non sottoposti a escape | Telegram rifiuta l'invio; due URL con un singolo underscore si annullano a vicenda, facendo sembrare il problema intermittente |
| Un secondo bot appena aggiunto non entra mai online | Le variabili dell'istanza vengono lette una sola volta all'avvio e un token duplicato viene ignorato (documentazione del canale) | Un avviso in logs/nanoclaw.error.log (add-telegram skill); Telegram consente un solo poller per token, quindi ogni bot necessita del proprio token BotFather |
La diagnostica ufficiale di primo livello di NanoClaw consiste in due file di log più ncl sessions list, ncl dropped-messages list e ncl wirings list. Nessuna versione rilasciata include un comando per verificare la disponibilità del canale, quindi il triage qui sotto si basa invece sulle righe di log.
# 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 installsPerché tutto sembra funzionare mentre gli ingressi sono inattivi
È un aspetto strutturale e la parte che fa perdere più tempo. Il README di NanoClaw descrive il percorso come app di messaggistica → router dell'host → database degli ingressi → container → database delle uscite → ritorno attraverso la consegna. La consegna esegue il polling del database delle uscite autonomamente, mentre una scansione dell'host ogni 60 secondi riattiva in modo indipendente i messaggi da eseguire e quelli ricorrenti. Gli ingressi sono l'unico stadio che dipende dal poller Telegram — proprio per questo il segnalatore dell'issue #3728 ha visto l'host rimanere attivo, la consegna in uscita continuare a funzionare e le attività pianificate continuare a essere eseguite per circa quattro giorni di totale silenzio in ingresso, con 11.178 errori consecutivi registrati.
L'hook di integrità che avrebbe dovuto rilevarlo non lo fa. La documentazione pubblicata dell'interfaccia adapter di NanoClaw afferma che isConnected() "non viene attualmente chiamato dall'host al di fuori dei test" e che "il bridge restituisce sempre true". Nel frattempo trunk è cambiato: un comando ncl status che segnala un flag di connessione per adapter è arrivato su main il 15 settembre 2026, dopo il rilascio della v2.3.0, rendendo la documentazione accurata per ogni versione rilasciata ma obsoleta per trunk. Considera quel comando come un dettaglio interno non rilasciato, non come una raccomandazione: è registrato come nascosto e solo per l'host e non compare in alcuna documentazione. Per Telegram, comunque, le due strade convergono: né la versione 4.29.0 né la 4.41.0 dell'adapter implementa affatto isConnected (entrambi i build dist sono stati sottoposti a grep per questa pagina), quindi il probe ricade in ogni caso su true.
Anche la documentazione presenta una lacuna corrispondente. La pagina di troubleshooting contiene una sezione intitolata "Webhook channel is silent" e nessun equivalente per il polling, mentre il percorso guidato "Agent never replies" inizia da "Did the router accept it?" con ncl dropped-messages list — un passaggio che presuppone già che il messaggio abbia raggiunto l'host. Quando il poller è inattivo non ci sono righe di messaggi eliminati da trovare, perché il router non ha mai visto il messaggio. L'issue #2989 registra lo stesso vicolo cieco per la propria causa: nessuna riga di log, nessuna riga di messaggi eliminati, nulla da cui eseguire il debug.
Non esiste una versione correttiva, quindi pianifica di conseguenza
L'issue #3728 è aperta con zero commenti, zero etichette e nessun milestone, e il timestamp di aggiornamento coincide ancora con quello di creazione del 6 settembre 2026. La versione più recente è la v2.3.0 del 24 agosto 2026, e l'unico commit sul branch channels dal 1° settembre è una correzione per Mattermost. Lo stesso vale per il caso del filtro obsoleto: la pull request che fisserebbe un elenco esplicito degli aggiornamenti è aperta contro channels dal 22 agosto 2026, e il sorgente del branch corrente non contiene alcuna occorrenza di allowedUpdates. Il blocco del singolo host che avrebbe impedito il caso dell'host duplicato è stato chiuso senza merge. Quindi la formulazione onesta è mitigazione, non un numero di versione.
Prima di scrivere una patch personalizzata, vale la pena sapere tre cose. Primo, una modifica locale a src/channels/telegram.ts non persiste: l'add-telegram skill copia quel file dal branch channels con l'istruzione di sovrascriverlo perché il branch è canonico, e l'update skill aggiorna ogni canale installato — esattamente il motivo per cui il segnalatore di #3728 perdeva la correzione a ogni aggiornamento. Secondo, il watchdog del segnalatore è tanto un avvertimento quanto una ricetta: la prima versione, basata solo sul contatore, ha causato un'interruzione peggiore di tre giorni, perché il poller finiva per essere arrestato invece di fallire, quindi non venivano registrati altri errori e il contatore non raggiungeva mai la soglia. La seconda versione usava due segnali indipendenti e non lasciava mai il poller arrestato. Nulla di tutto ciò è incluso, approvato o verificato indipendentemente. Terzo, qualunque cosa tu costruisca, testa il ripristino in entrambe le direzioni: il successo in uscita non dimostra nulla sugli ingressi, quindi il controllo importante è un nuovo messaggio inviato da una chat associata che produca una nuova riga in ingresso.
Un errore del canale Telegram non è un problema del modello o dell'API
Vale la pena dirlo chiaramente, perché la ricerca successiva più ovvia manda le persone nella direzione sbagliata. La documentazione delle credenziali di NanoClaw afferma che i token dei canali come TELEGRAM_BOT_TOKEN restano in .env e vengono usati dal processo host, non dai container, mentre le credenziali del modello risiedono nel vault e vengono inserite nelle richieste in uscita durante l'esecuzione. I messaggi in ingresso raggiungono il router e il database degli ingressi della sessione prima che venga scelto un provider, poiché il provider viene risolto quando viene avviato il container (documentazione dei provider dell'agent). Nessun base URL, chiave, gateway o cambio di provider ripara un loop di polling inattivo, un filtro degli aggiornamenti obsoleto, una collisione tra poller, la privacy del gruppo o una route IPv6 non funzionante.
Il vero punto di intersezione funziona al contrario. Il README di NanoClaw elenca Claude Code tra i requisiti proprio per /customize, /debug e ogni skill /add-channel, quindi per riparare un canale serve sull'host anche se i gruppi del tuo agent vengono eseguiti su qualcos'altro. I requisiti dell'host sono macOS o Linux, Windows tramite WSL2, Node.js 22 o successivo, pnpm 10 o successivo e Docker — e nota che nanoclaw.dev pubblicizza ancora Node.js 20 o successivo, mentre il README e il changelog della v2.3.0 rendono la versione 22 il requisito minimo inderogabile. Attieniti al changelog, che definisce l'aggiornamento una modifica incompatibile.
Quanto costano realmente NanoClaw e il suo canale Telegram
| Voce | Quanto costa | Provenienza |
|---|---|---|
| NanoClaw in sé | $0, con licenza MIT, nessun piano a pagamento e nessun account utente | nanoclaw.dev: "NanoClaw è gratuito e open source con licenza MIT." |
| L'account del portale della community | Gratuito e facoltativo; tutto il resto funziona senza di esso | Il README del progetto |
| Il token del bot Telegram | $0 per crearlo in BotFather e nulla da acquistare per una chat associata — il piano opzionale Paid Broadcasts di Telegram si applica solo oltre 30 messaggi al secondo | Telegram Bot API; la modalità polling significa inoltre che non sono necessari URL pubblici, webhook o porte aperte, secondo la documentazione del canale |
| Utilizzo del modello | Qualunque sia il costo applicato dal provider collegato; NanoClaw non addebita nulla per questo | FAQ di nanoclaw.dev: "Il tuo provider dell'agent potrebbe addebitare l'utilizzo del modello." |
| Docker | Necessario sull'host; si applicano i termini di abbonamento di Docker oltre le soglie di utilizzo gratuito | Non verificato per questa pagina — consulta la pagina dei prezzi di Docker prima di inserirlo nel budget |
Non esiste un piano a pagamento che ti permetta di risolvere pagando un bot che non risponde, ed è questa l'informazione utile che la tabella comunica. La spesa inizia solo quando il canale funziona di nuovo e l'agent risponde. Le cifre seguenti sono un calcolo illustrativo dei token, non costi misurati delle attività né un limite massimo di fatturazione: supponi una chat associata con 25 turni al giorno, 20.000 token di input non memorizzati nella cache e 900 token di output per turno, per 30 giorni. Le tariffe sono prezzi live del catalogo Kunavo per milione di token.
| Modello | Input / output per 1M | Stima mensile |
|---|---|---|
| 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 |
Scala il valore in base al tuo traffico prima di considerarlo un budget e nota l'ipotesi che incide di più: nulla viene servito dalla cache. Una sessione agent di lunga durata reinvia il contesto, quindi il comportamento della cache sposta questo numero più della differenza per token tra due modelli vicini. L'importo del catalogo Kunavo è un minimo di fatturazione, non un tetto massimo — quando l'upstream comunica il proprio addebito, la fattura è il maggiore tra il costo di catalogo e il costo upstream moltiplicato per il markup applicabile. La ricarica minima è $10 di credito prepagato, un minimo di finanziamento e non un costo per attività o un abbonamento; consulta i dettagli di fatturazione.
| Percorso del modello dell'agent | Vantaggioso quando | Cosa non fa |
|---|---|---|
| API diretta del fornitore | Rimani sul modello di punta di un unico fornitore e vuoi i termini di caching e batch del fornitore stesso | Un secondo fornitore significa un secondo account e un secondo saldo |
| Un gateway compatibile con OpenAI o Anthropic | Cambi modello per gruppo di agent e vuoi una sola chiave e un solo saldo | Il provider nativo di NanoClaw è Claude Agent SDK, quindi un base URL personalizzato deve parlare quel formato di comunicazione; un endpoint in formato OpenAI viene raggiunto tramite la skill del provider OpenCode, che instrada i modelli attraverso la configurazione propria di OpenCode |
| Un abbonamento | Un uso quotidiano intenso a tariffa fissa si adatta meglio a te rispetto ai token a consumo | NanoClaw non vende alcun abbonamento proprio; la tariffa fissa appartiene al provider |
| Un modello locale | Attività ridotte o private senza costi per modelli ospitati | La skill Ollama propria di NanoClaw è descritta come destinata a un percorso di configurazione precedente e non come un cambio diretto supportato sull'attuale main |
Nessuna di queste quattro scelte modifica il percorso Telegram. Per l'intero lato provider — le due variabili d'ambiente lette dalla configurazione, ciò che vede realmente il container e il ruolo di OpenCode e Codex — consulta Costi e provider dell'API NanoClaw. Se stai collegando il runtime Claude predefinito a un endpoint personalizzato, la guida all'integrazione di Claude Code e il riferimento al base URL illustrano la configurazione, e puoi creare un account Kunavo quando sei pronto a finanziare una chiave. Kunavo non ha testato NanoClaw a runtime e una guida di configurazione pubblicata è un riferimento di configurazione, non un test di compatibilità.
Domande frequenti
Perché il mio bot Telegram NanoClaw ha smesso di rispondere?
Inizia chiedendoti se i messaggi stanno ancora uscendo dall’host. Se le risposte e i messaggi pianificati arrivano ancora ma nulla di ciò che invii riceve risposta, il sospetto è il polling in ingresso: il problema #3728 di NanoClaw segnala che il ciclo di polling dell’adapter ritenta getUpdates per sempre con un limite massimo di backoff di 30 secondi, non rinuncia mai e non registra nulla quando il polling va a buon fine, quindi il guasto è invisibile. Se non viene inviato nulla, e il log mostra voci "Message delivered" con platformMsgId=undefined accanto ad avvisi "No adapter for channel type", la skill /debug di NanoClaw indica come causa due istanze del servizio in esecuzione contemporaneamente. I due casi hanno rimedi opposti, quindi identifica la firma prima di modificare qualsiasi cosa.
Esiste una versione corretta del bug di polling Telegram di NanoClaw?
No, al 21 settembre 2026. Il problema #3728 è aperto con zero commenti, zero etichette e nessuna milestone, e il relativo timestamp di aggiornamento coincide ancora con la data di apertura, il 6 settembre 2026. L’ultima release di NanoClaw è la v2.3.0 del 24 agosto 2026, quindi dal report non è stato distribuito nulla, e l’unico commit sul branch channels dal 1° settembre è una correzione per Mattermost. Chiunque ti dica di aggiornare a una versione specifica di NanoClaw per risolvere questo problema sta indicando una versione che non esiste.
Aggiornare @chat-adapter/telegram lo risolve?
Non il percorso di morte silenziosa. NanoClaw fissa @chat-adapter/telegram esattamente alla versione 4.29.0, pubblicata il 18 maggio 2026, mentre l’ultimo dist-tag di npm è la 4.41.0 del 18 settembre 2026. Entrambi i tarball sono stati scaricati e confrontati per questa pagina: il ramo di errore del trasporto getUpdates è sostanzialmente identico nelle due build — lo stesso contatore consecutiveFailures, lo stesso limite massimo di backoff di 30 secondi, la stessa riga di avviso, nessuna rinuncia e nessuna escalation, e un polling riuscito continua a non registrare nulla. La 4.41.0 ha riscritto altre parti del ciclo. Questa pagina lo afferma come fatto relativo al codice e non raccomanda di aumentare il pin: la skill add-telegram di NanoClaw afferma che la policy della supply chain rifiuta gli intervalli, le due pull request di aggiornamento lette per questa pagina (#3460 e #3570) sono aperte e non unite, e qui nessuno ha testato cos’altro cambi un aggiornamento.
Cambiare provider API o URL di base risolverà un problema Telegram?
No. La documentazione delle credenziali di NanoClaw stabilisce che i token dei canali come TELEGRAM_BOT_TOKEN restano in .env e vengono usati dal processo host, non dai container, mentre le credenziali del modello entrano nel vault e vengono iniettate nel traffico dei container. Un messaggio Telegram in ingresso raggiunge il router e il database inbound della sessione prima che venga risolto un provider, cosa che avviene quando viene avviato il container. Pertanto un endpoint, una chiave o un gateway diverso non può riparare un ciclo di polling bloccato, un filtro degli aggiornamenti obsoleto lato server, una collisione tra poller, Group Privacy o un percorso IPv6 guasto. L’unico collegamento reale funziona al contrario: il README di NanoClaw elenca Claude Code come requisito per /debug e per ogni skill /add-channel, quindi la riparazione del canale ne richiede la presenza sull’host anche in un’installazione in cui l’agente viene eseguito altrove.
Il bot risponde ai messaggi diretti ma ignora il gruppo. Perché?
Di solito si tratta dell’impostazione Group Privacy di Telegram, non di un difetto di NanoClaw. La skill add-telegram di NanoClaw afferma che con Group Privacy attiva il bot vede solo i comandi e le risposte indirizzati, non il testo ordinario, e che devi disattivarla in BotFather sotto /mybots, il tuo bot, Bot Settings, Group Privacy — quindi rimuovere e aggiungere nuovamente il bot al gruppo affinché la modifica abbia effetto. Un caso distinto appare simile ma non lo è: il problema #2989 di NanoClaw segnala che un token del bot precedentemente sottoposto a polling con un filtro allowed_updates più restrittivo conserva per sempre quel filtro lato server, scartando silenziosamente i post dei canali mentre i messaggi diretti e i gruppi continuano a funzionare.
Il pairing non viene mai completato, ma il bot funziona ancora. Qual è il problema?
Il problema #3162 di NanoClaw descrive esattamente questa situazione: se la chiamata getMe all’avvio del canale fallisce una volta, il nome utente del bot viene memorizzato come null per tutta la durata del processo e ogni codice di pairing inviato viene trattato come un messaggio ordinario, senza alcun tentativo registrato, mentre l’installer resta in attesa per sempre. L’unica traccia è una singola riga di avviso all’avvio, minuti prima del tentativo di pairing, e il problema afferma che un riavvio senza altre modifiche risolve il caso. L’adapter attuale del branch channels effettua ancora quella ricerca una sola volta, senza retry, e memorizza il risultato. Nota inoltre che la documentazione di NanoClaw descrive un codice monouso di 6 cifre con fino a 5 codici rigenerati per esecuzione, mentre il problema #3162 lo definisce un codice di 4 cifre; attieniti alla documentazione.
Verificato il 21 settembre 2026: il record del repository nanocoai/nanoclaw e l'elenco dei rilasci, gli stati aperto/chiuso delle issue #2377, #2989, #3162, #3569 e #3728 e delle pull request #2225, #2697, #3449, #3460 e #3570, il sorgente dell'adapter Telegram del branch channels, sia il build 4.29.0 fissato sia l'attuale build 4.41.0 dell'adapter da npm, la documentazione di NanoClaw relativa a canali, credenziali, troubleshooting e interfaccia adapter, le sue skill add-telegram e debug e la pagina Bot API di Telegram. Nulla di questa pagina è stato eseguito su un'installazione NanoClaw in esecuzione. Le tariffe dei token Kunavo provengono dal catalogo live e le cifre in dollari sono un calcolo illustrativo dei token.