Telegram do NanoClaw não responde: polling, permissões e verificações de execução

Quando um bot do Telegram no NanoClaw para de responder, o primeiro passo não é uma correção — é decidir se as mensagens recebidas estão chegando ao host, porque duas falhas do NanoClaw relatadas separadamente produzem essa reclamação com sinais opostos. Em uma, o recebimento morre enquanto a entrega de saída e as tarefas agendadas continuam funcionando, então todas as superfícies verificadas pelo operador parecem saudáveis. Na outra, nada é enviado, e o log marca como entregues mensagens que nunca foram enviadas. A mesma reclamação, causas diferentes, e um remédio para uma não faz nada pela outra.

Uma desambiguação antes de qualquer coisa, porque os resultados de busca para essa expressão são em sua maioria sobre outro produto. OpenClaw é um projeto separado e muito maior — 390.207 estrelas e uma licença NOASSERTION quando o registro do repositório na API foi lido em 21 de setembro de 2026 — e a própria página inicial do NanoClaw se posiciona contra ele. NanoClaw é nanocoai/nanoclaw: MIT, não arquivado, não é um fork, 30.818 estrelas, 1.068 issues abertas, último push em 19 de setembro de 2026 (GitHub API, mesma data). O endereço antigo qwibitai/nanoclaw retorna 301 para ele, portanto é o mesmo projeto renomeado, não um segundo projeto. Os dois projetos não compartilham nenhum caminho de código do Telegram — o NanoClaw instala seu próprio adaptador copiando o código-fonte de seu branch channels (habilidade add-telegram) — portanto uma solução do OpenClaw não se aplica. Para a diferença completa, consulte NanoClaw vs OpenClaw.

Leia o sinal antes de tocar em qualquer coisa

Cada linha abaixo é uma falha distinta, relatada separadamente, com sua própria verificação de confirmação. Todas as oito foram lidas em 21 de setembro de 2026 no próprio rastreador de issues do NanoClaw, nas skills lançadas e na documentação do canal.

Os diagnósticos oficiais de primeira linha do NanoClaw são dois arquivos de log mais ncl sessions list, ncl dropped-messages list e ncl wirings list. Nenhuma versão lançada oferece um comando de verificação de atividade do canal, portanto a triagem abaixo se apoia nas linhas de 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 installs

Por que tudo parece saudável enquanto o recebimento está morto

Isso é estrutural e é a parte que mais desperdiça tempo. O README do NanoClaw descreve o caminho como aplicativo de mensagens para o roteador do host, depois para um banco de dados de entrada, para dentro do contêiner, para um banco de dados de saída e de volta pela entrega. A entrega consulta o banco de dados de saída por conta própria, e uma varredura do host a cada 60 segundos desperta independentemente as mensagens cujo horário de envio chegou e as mensagens recorrentes. O recebimento é a única etapa que depende do poller do Telegram — exatamente por isso o autor da issue #3728 viu o host permanecer ativo, a entrega de saída continuar funcionando e as tarefas agendadas continuarem sendo executadas durante cerca de quatro dias de silêncio total no recebimento, com 11.178 falhas consecutivas registradas.

O hook de saúde que deveria ter detectado isso não funciona. A referência da interface do adaptador publicada pelo NanoClaw afirma sobre isConnected() que ele "atualmente não é chamado pelo host fora dos testes" e que "a ponte sempre retorna true". O trunk avançou desde então: um comando ncl status que informa uma flag de conexão por adaptador entrou em main em 15 de setembro de 2026, depois do lançamento da v2.3.0, tornando a documentação correta para todas as versões lançadas e obsoleta para o trunk. Trate esse comando como implementação interna não lançada, não como orientação — ele é registrado como oculto e apenas para o host e não aparece em nenhuma documentação. No Telegram, os dois caminhos acabam se encontrando: nem a versão 4.29.0 nem a 4.41.0 do adaptador implementa isConnected (as duas builds de distribuição foram pesquisadas para esta página), então a sonda recorre a true de qualquer forma.

A documentação tem uma lacuna correspondente. A página de solução de problemas contém uma seção intitulada "Webhook channel is silent" e nenhuma equivalente para polling, e seu passo a passo "Agent never replies" começa em "Did the router accept it?" com ncl dropped-messages list — uma etapa que já pressupõe que a mensagem chegou ao host. Quando o poller está morto, não há linhas de mensagens descartadas para encontrar, porque o roteador nunca viu a mensagem. A issue #2989 registra o mesmo beco sem saída para sua própria causa: nenhuma linha de log, nenhuma linha de mensagem descartada, nada para depurar.

Não há uma versão corrigida, então planeje em torno disso

A issue #3728 está aberta, com zero comentários, zero rótulos e nenhum milestone, e seu timestamp de atualização ainda é igual ao timestamp de criação de 6 de setembro de 2026. A versão mais recente é a v2.3.0, de 24 de agosto de 2026, e o único commit no branch channels desde 1º de setembro é uma correção do Mattermost. O mesmo vale para o caso do filtro obsoleto: o pull request que fixaria uma lista explícita de atualizações está aberto contra channels desde 22 de agosto de 2026, e o código-fonte do branch atual não contém nenhuma ocorrência de allowedUpdates. O bloqueio do host de instância única que teria evitado o caso de host duplicado foi encerrado sem merge. Portanto, o enquadramento honesto é mitigação, não um número de versão.

Vale a pena saber três coisas antes de escrever seu próprio patch. Primeiro, uma edição local em src/channels/telegram.ts não persiste: a skill add-telegram copia esse arquivo do branch channels com a instrução de sobrescrevê-lo porque o branch é canônico, e a skill de atualização atualiza todos os canais instalados — exatamente como o autor da #3728 perdeu essa correção a cada atualização. Segundo, o watchdog do autor do relatório é tanto um aviso quanto uma receita: a primeira versão, baseada apenas no contador, causou uma interrupção de três dias pior, porque o poller acabou parado em vez de falhar, então nenhuma falha adicional foi registrada e o contador nunca atingiu seu limite. A segunda versão usou dois sinais independentes e nunca deixou o poller parado. Nada disso foi lançado, endossado ou verificado de forma independente. Terceiro, seja qual for o seu desenvolvimento, teste a recuperação nas duas direções: o sucesso de saída não prova nada sobre o recebimento, portanto a verificação relevante é uma mensagem nova enviada do chat pareado que produza uma nova linha de entrada.

Uma falha de canal do Telegram não é um problema de modelo ou API

Vale dizer isso claramente, porque a próxima busca óbvia leva as pessoas na direção errada. A documentação de credenciais do NanoClaw diz que tokens de canais como TELEGRAM_BOT_TOKEN permanecem em .env e são usados pelo processo do host, não pelos contêineres, enquanto as credenciais do modelo ficam no vault e são injetadas nas solicitações de saída durante o tráfego. As mensagens recebidas chegam ao roteador e ao banco de dados de entrada da sessão antes que qualquer provedor seja escolhido, pois o provedor é resolvido quando o contêiner é iniciado (agent providers documentation). Nenhuma troca de URL base, chave, gateway ou provedor repara um loop de polling morto, um filtro de atualização obsoleto, uma colisão de pollers, o Group Privacy ou uma rota IPv6 quebrada.

A verdadeira interseção ocorre no sentido inverso. O README do NanoClaw lista o Claude Code entre seus requisitos especificamente para /customize, /debug e todas as skills /add-channel, portanto reparar um canal exige que ele esteja no host mesmo que os grupos do seu agente sejam executados em outra coisa. Os requisitos do host são macOS ou Linux, Windows por meio do WSL2, Node.js 22 ou mais recente, pnpm 10 ou mais recente e Docker — e observe que nanoclaw.dev ainda anuncia Node.js 20 ou mais recente, enquanto o README e o changelog da v2.3.0 estabelecem 22 como piso obrigatório. Siga o changelog, que chama a atualização de breaking.

Quanto o NanoClaw e seu canal do Telegram realmente custam

Não há um plano pago para comprar e se livrar de um bot que não responde, que é a informação útil transmitida pela tabela. O dinheiro só começa a ser gasto quando o canal volta a funcionar e o agente responde. Os valores abaixo são aritmética ilustrativa de tokens, não custos de tarefas medidos nem um teto de cobrança: suponha um chat pareado com 25 turnos por dia, 20.000 tokens de entrada não armazenados em cache e 900 tokens de saída por turno, durante 30 dias. As tarifas são preços atuais do catálogo da Kunavo por milhão de tokens.

Escale isso de acordo com seu próprio tráfego antes de tratá-lo como um orçamento e observe a suposição que mais pesa: nada é servido a partir do cache. Uma sessão de agente de longa duração reenvia o contexto, portanto o comportamento do cache altera esse número mais do que a diferença por token entre dois modelos vizinhos. O valor do catálogo da Kunavo é um piso de cobrança, não um teto — quando o upstream informa sua cobrança, a conta é o maior valor entre o custo do catálogo e o custo do upstream multiplicado pela margem aplicável. O recarregamento mínimo é de $10 em crédito pré-pago, um mínimo de financiamento, não uma taxa por tarefa nem uma assinatura; consulte billing details.

Nenhuma dessas quatro opções toca no caminho do Telegram. Para conhecer a parte do provedor em detalhes — as duas variáveis de ambiente lidas pela configuração, o que o contêiner realmente vê e onde OpenCode e Codex se encaixam — consulte NanoClaw API costs and providers. Se você estiver conectando o runtime Claude padrão a um endpoint personalizado, o Claude Code integration guide e a base URL reference explicam a configuração, e você pode criar uma conta Kunavo quando estiver pronto para financiar uma chave. A Kunavo não testou o NanoClaw em runtime, e um guia de configuração publicado é uma referência de configuração, não um teste de compatibilidade.

Perguntas frequentes

Verificado em 21 de setembro de 2026: o registro do repositório nanocoai/nanoclaw e a lista de releases, os estados aberto/fechado das issues #2377, #2989, #3162, #3569 e #3728 e dos pull requests #2225, #2697, #3449, #3460 e #3570, o código-fonte do adaptador Telegram do branch channels, as builds do adaptador 4.29.0 fixada e 4.41.0 atual do npm, a documentação de canais, credenciais, solução de problemas e interface de adaptadores do NanoClaw, suas skills add-telegram e debug e a página da Bot API do Telegram. Nada nesta página foi executado contra uma instalação do NanoClaw em funcionamento. As tarifas de tokens da Kunavo vêm do catálogo atual, e os valores em dólares são aritmética ilustrativa de tokens.