OpenClaw no WhatsApp: como funciona conversar com o agente pelo mensageiro?

Fala aí, beleza? Pedir uma tarefa pro agente no terminal é uma coisa: tu abre a sessão, digita, ele responde ali mesmo, e a única pessoa capaz de mandar entrada é quem está na máquina

Agora, mandar mensagem pra ele no WhatsApp é OUTRA história

A porta de entrada deixa de ser o teu teclado e vira um app que qualquer contato, e qualquer grupo, consegue tocar

É exatamente esse o modelo do OpenClaw: o mensageiro não é um enfeite, ele é a interface do assistente

E por isso a decisão de vincular uma conta merece ser entendida ANTES de sair lendo QR code por aí, beleza? Bora destrinchar isso…

O que é o OpenClaw e por que o mensageiro vira a interface

O OpenClaw é um assistente pessoal open source que roda nos dispositivos do próprio usuário e atende nos canais de mensagem que ele já usa

A peça central é um Gateway único, que conecta modelos, ferramentas, canais e apps companheiros

E ele foi pensado para um único operador (single operator), não pra virar central de atendimento de uma empresa

E o que esse Gateway faz, na prática?

Ele concentra os canais de mensagem ao mesmo tempo: WhatsApp, Telegram, Slack, Discord, Signal e outros

O ciclo é simples de desenhar na cabeça: chegou mensagem, o Gateway roteia pra sessão do agente, espera a resposta e devolve pelo canal de origem

Se você conhece um roteador de rede, a analogia é essa: uma caixa no meio decidindo pra onde cada coisa vai e por onde volta

O detalhe que muda tudo é o segundo passo: a sessão do agente é a mesma, o canal é que muda

Formação Recomendada

Formação Agentes de IA

Domine a criação de Agentes de IA e Venda para Empresas

• 402 aulas
• 32 projetos
• 38h 19min

Conhecer formação

De onde veio esse projeto

Segundo reportagem da Forbes, o projeto foi criado por Peter Steinberger e trocou de nome duas vezes em poucos dias

Ainda de acordo com a Forbes, saiu de Clawdbot para Moltbot em 27 de janeiro de 2026, após pedido da Anthropic por semelhança com Claude, e de Moltbot para OpenClaw em 30 de janeiro de 2026

E não é projetinho de fim de semana: ele ultrapassou o React e virou o software mais estrelado do GitHub, cruzando 250.829 estrelas em 3 de março de 2026

Insano, né? 😀

WhatsApp, terminal ou navegador: o que muda na prática

Antes de configurar qualquer coisa, vale enxergar o que realmente muda quando você troca a interface do agente

O ponto sensível não é conforto, é superfície de entrada

Repara que a coluna do WhatsApp é a única que ganha linhas de permissão

Não é frescura de documentação: é consequência direta de plugar o agente num canal que outras pessoas alcançam sem pedir licença

Quem pode acionar o agente quando ele mora no seu WhatsApp

Essa é a parte que separa quem entendeu o modelo de quem só pareou e torceu 😛

O controle vem em camadas, e cada camada responde uma pergunta diferente

Camada 1: quem pode te mandar DM

A primeira trava é a política de mensagem privada

Com dmPolicy em allowlist, só entra quem está na lista, e a lista é de telefones em formato E.164

channels.whatsapp.allowFrom: ["+15555550123", "+447700900123"]

A orientação da documentação é direta: sempre defina channels.whatsapp.allowFrom e nunca rode o canal aberto ao mundo

Tome cuidado! Canal aberto ao mundo não é "agente popular", é qualquer número virando entrada do teu assistente

Camada 2: pareamento pra quem você ainda não conhece

Com a política de DM em pairing, o remetente desconhecido recebe um código curto

E aqui está o detalhe que mais importa: a mensagem dele NÃO é processada até você aprovar

Os códigos de pareamento expiram em 1 hora, e o bot só manda a mensagem de pareamento quando uma nova solicitação é criada

A própria documentação resume esse aviso como aproximadamente uma vez por hora por remetente

Isso evita aquele efeito bola de neve de o bot ficar respondendo pedido de pareamento sem parar

Camada 3: grupo é outro mundo

Aprovar um DM no pareamento NÃO é a mesma coisa que autorizar grupo

O store de pareamento libera apenas as conversas privadas, ponto

Em grupos existem dois controles distintos, e confundir os dois é o erro clássico:

• autorização de gatilho (trigger authorization): quem pode acionar o agente, via groupPolicy, groups, groupAllowFrom e allowlists por canal
• visibilidade de contexto (context visibility): o que o agente enxerga daquela conversa

Um diz quem manda o agente trabalhar, o outro diz o que ele lê

Camada 4: menção obrigatória e o buffer de contexto

Em grupo, a resposta exige menção, a menos que você desative o gating de menção para aquele grupo

Vale @-mention real (mentionedJids), regex configurado, os dígitos E.164 do bot no texto ou uma resposta citando mensagem do bot

E o que acontece com todo o resto que rolou no grupo enquanto ninguém chamou o agente?

As mensagens não processadas ficam em buffer e são injetadas como contexto quando o bot finalmente é acionado, com limite padrão de 50 mensagens, configurável em channels.whatsapp.historyLimit ou messages.groupChat.historyLimit

Então sim: mesmo sem responder, aquele papo do grupo pode virar contexto depois

Se liga nisso antes de jogar o bot no grupo da firma 😀

E pra fechar a camada, as allowlists de pareamento moram no disco da máquina, em ~/.openclaw/credentials/<canal>-allowFrom.json (conta padrão) ou <canal>-<accountId>-allowFrom.json para contas não padrão

Número dedicado ou WhatsApp pessoal: qual cenário é o seu

Aqui a documentação não fica em cima do muro, e eu acho isso ótimo

Cenário 1: número dedicado (a recomendação oficial)

A orientação é usar um número de WhatsApp dedicado para o assistente

O motivo é bem concreto: se você vincula seu WhatsApp pessoal, toda mensagem que chega pra você passa a ser entrada do agente

E isso raramente é o que a pessoa queria quando pensou "vou colocar meu agente no zap"

Cenário 2: número pessoal com self-chat

Existe o modo número pessoal com self-chat, pra quem quer conversar consigo mesmo e usar isso como painel do agente

O onboarding grava uma baseline com dmPolicy em allowlist, allowFrom incluindo o seu próprio número e selfChatMode em true

Tem uma limitação importante nesse modo: o agente não consegue ligar para si mesmo

Pra chamar o seu número pessoal, é preciso um número OpenClaw dedicado

E como o canal entra no jogo

O WhatsApp é instalado sob demanda como plugin, não vem carregado por padrão

openclaw onboard
openclaw channels add --channel whatsapp
openclaw channels login --channel whatsapp

O openclaw onboard e o openclaw channels add --channel whatsapp oferecem instalar o plugin na primeira vez

E o openclaw channels login --channel whatsapp oferece o mesmo fluxo se o plugin estiver faltando

A instalação vai pela rota do ClawHub (clawhub:@openclaw/whatsapp) com fallback para npm

Se você conhece npm ou composer, é a mesma ideia de puxar um pacote sob demanda

E o Gateway só carrega o plugin externo quando o canal está de fato ativo

A conexão em si é por pareamento com QR code do WhatsApp Web: o QR de login vincula uma conta WhatsApp ao OpenClaw

O que a experiência com agente no WhatsApp já ensina

Deixa eu ser honesto no recorte: a minha mão na massa com agente atendendo por WhatsApp foi em OUTRA pilha, com n8n e Evolution API, não com OpenClaw

Então nada do que eu conto aqui vale como instrução de configuração do OpenClaw, e você não deve copiar esses passos pra lá

Mas o MODELO de operar um agente por mensageiro é o mesmo, e ele ensina umas coisas que economizam dor de cabeça

O ciclo é sempre o mesmo. No vídeo eu mostro a mensagem saindo do WhatsApp, entrando num fluxo de automação, passando pela IA e voltando como resposta pra mesma conversa

Se você entendeu esse desenho, entendeu qualquer agente em mensageiro, incluindo o roteamento do Gateway que a gente viu lá em cima

Ambiente antes do fluxo. Eu aviso isso logo no começo: o ambiente precisa estar configurado em servidor próprio antes de montar o fluxo

Sem essa etapa anterior, as integrações simplesmente não funcionam e o resto do tutorial dá errado

O gatilho é o coração. Na minha montagem, o gatilho é um webhook: o mensageiro avisa o sistema no meio, que dispara o fluxo e devolve a resposta

No OpenClaw o papel de "sistema no meio" é do Gateway, mas a lógica de acionamento continua sendo a pergunta central: o que faz o agente acordar?

Ligar tudo de uma vez vira bagunça. Quando testei, eu habilitei só os eventos que ia usar de verdade, e o essencial pra começar é o recebimento de mensagem

Esse instinto conversa direto com o mention gating e as allowlists do OpenClaw: menos gatilho ativo, menos ruído, menos surpresa

Valida o primeiro elo antes de sonhar alto. Eu paro o tutorial pra mandar uma mensagem real de outro WhatsApp e conferir se o fluxo recebeu

Se esse passo não fica verde, tudo depois vai falhar

O erro comum me pegou ao vivo. O agente falhou na primeira execução porque o campo de entrada estava apontando pro chat interno da ferramenta, e não pra mensagem vinda do WhatsApp

Corrigi apontando manualmente e aí passou

É um erro besta que consome uma tarde se você não sabe onde olhar

Identidade importa na volta. Pra devolver a resposta eu preciso puxar três coisas do webhook: nome da instância, número do destinatário e o texto gerado pelo agente

Ou seja: o mensageiro sempre te obriga a saber PRA QUEM você está respondendo, e isso é a mesma preocupação de allowlist vista por outro ângulo

Custo durante a montagem. Eu recomendo montar e testar o sistema inteiro com modelos menores e mais baratos, pra gastar pouco no desenvolvimento, e só depois trocar por um modelo mais avançado se quiser mais performance na resposta

Resumindo o recorte: a pilha era outra, mas o hábito que fica é o mesmo, você fecha a porta e valida o primeiro elo antes de sair automatizando

No OpenClaw, esse mesmo hábito tem nome e lugar: allowlist, pareamento e mention gating

Se você quiser ver esse caminho detalhado, eu já escrevi sobre agente no WhatsApp com n8n por aqui, e também sobre boas práticas em agentes multicanal

Bora ver na prática?

Vale conectar? Os riscos que entram na conta

Agora a parte que ninguém gosta de ler, mas que é a mais importante do post

O protocolo não é oficial

O canal WhatsApp do OpenClaw é production-ready via WhatsApp Web (Baileys), ou seja, pelo protocolo não oficial do WhatsApp Web

A própria biblioteca Baileys declara não ser afiliada, associada, autorizada nem endossada pelo WhatsApp

Ela orienta uso por conta e risco do usuário, e os mantenedores afirmam que não endossam usos que violem os Termos de Serviço do WhatsApp

Do outro lado do balcão, o WhatsApp afirma que os produtos não são feitos para mensagens em massa ou automatizadas, e que o uso não autorizado desses recursos sempre foi violação dos Termos de Serviço, podendo levar a banimento da conta

Então a leitura honesta é essa: existe risco declarado pelas duas pontas, e quem assume é você

Por isso a recomendação do número dedicado deixa de ser conforto e vira gestão de risco 😅

O sandbox não te salva sozinho

Um ponto que muita gente entende errado: o sandbox é opt-in

O processo do Gateway SEMPRE continua no host, e só a execução de ferramentas vai para o sandbox quando ele é habilitado

E o modo elevado usa allowlist própria de remetentes, tools.elevated.allowFrom, com listas por canal

Ou seja: quem pode acionar e quem pode acionar com poder são duas listas diferentes

A ordem certa de travar as coisas

A documentação sugere uma ordem pra cenários abertos, e ela faz todo sentido:

1. travar primeiro DMs e grupos, com pareamento e allowlists
2. depois apertar política de ferramentas e sandbox
3. e corrigir imediatamente exposição de rede pública (bind na LAN, Funnel, falta de auth)

A doc oficial mantém até um runbook específico de Gateway exposure, o que já diz muito: Gateway acessível de fora é tratado como incidente, não como detalhe de config

Versão em dia não é papo de paranoico

A CVE-2026-25253 é uma falha de exfiltração de token de autenticação que leva a execução remota de código em um clique, com CVSS 8.8

Ela afeta versões anteriores à 2026.1.29, corrigida nessa versão

É o tipo de coisa que transforma "deixei rodando aqui em casa" num problema bem maior que perder uma conversa

Conclusão

O recado central é esse: entender o modelo vem ANTES de vincular conta

Saber o que o Gateway faz, quem consegue acionar o agente e o que ele enxerga da conversa muda completamente a sua avaliação de risco

Porque no terminal a pergunta é "o que eu peço pra ele", e no WhatsApp a pergunta vira "quem mais consegue pedir"

O próximo passo é bem concreto:

• decida entre número dedicado (a recomendação oficial) e o modo self-chat no número pessoal, sabendo que nesse modo o agente não liga pra si mesmo
• defina channels.whatsapp.allowFrom ANTES de qualquer teste, nunca depois
• escolha conscientemente entre dmPolicy em allowlist e em pairing, e lembra que aprovar DM não libera grupo
• e mantenha a versão em dia, com a 2026.1.29 como piso por causa da CVE-2026-25253

Agente em mensageiro é muito massa, dá aquela sensação de ter um assistente de verdade no bolso

Só que o mensageiro é uma porta, e porta boa é porta com fechadura configurada 🙂

até o próximo post!