Hermes Agent no Discord não responde: correções

Seu bot está online e te ignorando

A bolinha verde está acesa. O bot aparece na lista de membros do servidor. Você @menciona, manda um slash command, escreve uma mensagem normal e nada volta. Sem erro nos logs, sem resposta no canal. O Discord mostra o bot como ativo e o Hermes Agent mostra o gateway como conectado.

Quase todos os casos que a gente vê se resumem a uma de quatro causas. Três delas falham em silêncio por design, e por isso o bot parece saudável enquanto não faz nada. Este post cobre cada causa, como confirmar que é a sua e a correção exata.

Causa 1: o Message Content Intent está desativado

É a causa mais comum de um bot do Discord que conecta e depois ignora qualquer mensagem comum. Sintoma: seus slash commands funcionam, mas não acontece nada quando você escreve uma mensagem normal ou uma resposta. Nos logs você vê chegar eventos MESSAGE_CREATE, mas o campo content está vazio.

O que acontece: Message Content é um intent privilegiado do gateway. O Discord envia ele desativado por padrão. Sem ele, seu bot recebe cada evento de mensagem mas não pode ver o texto, então qualquer handler que tente casar por palavra-chave, menção ou prefixo falha em silêncio.

A correção: abra o Discord Developer Portal, escolha sua aplicação, entre em Bot na barra lateral, desça até Privileged Gateway Intents e ative Message Content Intent. Salve.

Para bots em menos de 100 servidores não precisa aprovação, o toggle vale na hora. Acima de 100 servidores você precisa mandar a app para verificação e o Discord aprova o intent separadamente.

Não precisa reiniciar o Hermes Agent depois da mudança. A próxima mensagem já vai chegar com o campo content populado.

Causa 2: você convidou a aplicação errada

Essa dói porque à primeira vista está tudo certo. Existe um bot no servidor, ele está online e tem o avatar certo. Mas escreva o que escrever, ele nunca responde.

O que acontece: provavelmente você criou várias aplicações no Discord durante a configuração (uma de teste, a real, alguma renomeada), e a URL de convite que você usou aponta para uma aplicação diferente daquela cujo token o Hermes Agent está rodando. O Discord conecta as duas apps ao gateway sem problema, as duas aparecem online, mas só a app cujo token você tem recebe eventos do seu servidor, e se essa app não estiver convidada, ela não recebe nada.

Confira primeiro: no Developer Portal abra a aplicação cujo token está no seu .env do Hermes Agent e copie o Application ID de General Information. Depois, no seu servidor do Discord, clique com o botão direito no bot na lista de membros e escolha Copiar ID de usuário. Se esses dois IDs não baterem, você convidou outra app.

A correção: regenere a URL de convite OAuth2 para a aplicação certa (os scopes exatos estão na Causa 3), remova o bot errado do servidor e convide o certo. Confirme que os IDs batem antes de seguir.

Causa 3: o convite não incluiu bot ou applications.commands

Se seu bot aparece no servidor mas nunca recebe slash commands, ou nem aparece como um bot real, a URL de convite OAuth2 foi gerada com os scopes errados.

O OAuth2 do Discord exige dois scopes separados para uma instalação de bot completa:

• bot, que é o que faz a aplicação convidada virar um usuário bot no servidor.
• applications.commands, que é o que permite ao bot registrar e receber slash commands.

Sem o primeiro, o Discord instala a app como uma integração e não como um membro bot, e o token não tem em quem se ancorar. Sem o segundo, o bot é um membro real mas os slash commands não se registram, então /qualquercoisa devolve A interação falhou ou nem autocompleta.

A correção: no Developer Portal vá em OAuth2 na barra lateral, entre em URL Generator, marque bot e applications.commands na seção Scopes, e no painel de Bot Permissions que aparece abaixo marque no mínimo:

• Send Messages
• Read Message History
• Embed Links
• Attach Files
• Use Slash Commands

Copie a URL gerada no rodapé, abra no navegador, escolha seu servidor e confirme. Uma URL mínima válida fica assim:

https://discord.com/oauth2/authorize?client_id=<APPLICATION_ID>&scope=bot+applications.commands&permissions=277562616896

Se seu bot precisar entrar em canais de voz para responder por TTS, marque também Connect e Speak na grade de permissões e convide de novo. O Discord atualiza a associação existente em vez de criar duplicata.

Causa 4: o canal nega a role do bot

As permissões no nível de servidor são só metade da história. O Discord aplica overrides de canal e de categoria por cima das permissões da role, e um único deny no nível do canal em Send Messages ou Read Message History silencia um bot que funciona no resto do servidor.

Sintoma: seu bot responde em alguns canais e em outros não. Ou o bot está mudo em todos os canais, mas só neste servidor, mesmo que o mesmo bot funcione no seu servidor de teste.

O que acontece: overrides de canal pesam mais que as permissões da role. Se alguém do seu servidor negou Send Messages para @everyone neste canal, ou restringiu a uma role que seu bot não tem, seu bot não posta ali mesmo tendo Send Messages no servidor. Read Message History é uma permissão separada de View Channel, então um bot pode ver uma mensagem chegando e ainda assim falhar em responder se o histórico estiver negado, porque algumas skills do Hermes Agent leem contexto recente antes de responder.

Confira primeiro: clique com o botão direito no canal afetado, Editar canal, Permissões, e olhe a role do seu bot (ou @everyone se o bot não tem role). Procure um X vermelho em qualquer um de: View Channel, Send Messages, Read Message History, Send Messages in Threads, Use Application Commands.

A correção: ou adicione um ✓ explícito para a role do bot no canal afetado, ou remova o deny no nível da categoria (denies de categoria caem sobre todos os canais dentro). Se seu bot precisa responder dentro de threads, Send Messages in Threads é uma permissão à parte e precisa da própria concessão. No tópico de suporte do Discord sobre overrides de canal você encontra as regras completas de precedência.

Ordem de diagnóstico que economiza tempo

Quando um bot fica mudo, siga as causas nesta ordem em vez de pular para a correção mais chamativa:

1. Compare Application ID e User ID do bot. Sessenta segundos, pega o caso da app errada antes de mexer em qualquer coisa.
2. Cheque o Message Content Intent. Sessenta segundos no Developer Portal, resolve a maior parte dos bots mudos com um único toggle.
3. Olhe seus eventos recebidos. Se você rodar o Hermes Agent com HERMES_LOG_LEVEL=debug, você vê se o bot está recebendo eventos e se o campo content das mensagens está vazio.
4. Revise de novo os scopes do convite. Se o sintoma são os slash commands, essa costuma ser a resposta. Convide de novo com os dois scopes marcados.
5. Audite os overrides de canal. Só vale a pena depois de descartar as quatro anteriores, porque é o mais demorado de conferir e a causa menos frequente quando o bot está mudo em todo lugar.

Para o caminho completo de instalação no Discord do zero, veja o guia de setup do Hermes Agent no Discord. Se seu bot não está conseguindo conectar ao Discord (em vez de conectar e ficar mudo), o post Hermes Agent Docker container keeps restarting cobre os crash loops do gateway.

Quando você prefere não brigar com o Discord toda semana

Os intents, o modelo de scopes e a matriz de overrides por canal do Discord são o que são. Se você acha que um agente conversacional simples não deveria exigir fluxo OAuth e revisão de intent privilegiado para dar um oi, comece com a Hermify. A Hermify roda um Hermes Agent gerenciado no Telegram com a mesma memória e as mesmas skills, no ar em cerca de um minuto, sem configuração de gateway para cuidar.

Fontes

• Discord Message Content Intent Review Policy
• Discord Bot Intents and the 2026 API Evolution
• Documentação OAuth2 do Discord
• Tópico de suporte do Discord sobre Read Message History