Acionando o OpenClaw a partir do Gmail

Você quer que o assistente reaja quando um e-mail chega: uma nova fatura, um pedido de suporte, um aviso de deploy que falhou. A ligação óbvia, apontar o Gmail para o agente com quem você já conversa, dá a qualquer desconhecido que saiba o seu endereço um turno em um agente que controla o seu shell, os seus arquivos e o seu navegador. O caminho do Gmail no OpenClaw existe para evitar isso, e ele é uma cadeia de peças, e não um interruptor.

Como uma mensagem do Gmail chega a um agente

• O Google Pub/Sub é o transporte. Um watch do Gmail em um marcador publica os eventos da caixa de entrada em um tópico, o Pub/Sub os envia por push para o processo gog gmail watch serve, e esse observador encaminha os dados do e-mail para o hook HTTP do Gateway. Ele nunca carrega um handler interno HOOK.md: este é o hook externo de entrada, e não o sistema de eventos interno ao processo.
• Os pré-requisitos são específicos: a CLI gcloud, o gog autorizado para a conta do Gmail observada, os hooks ativados no OpenClaw, um endpoint de push HTTPS que o Pub/Sub consiga de fato alcançar (o Tailscale Funnel, na configuração recomendada) e um backend de sandbox funcionando, cuja imagem você precisa construir antes da primeira execução se ficar no backend Docker padrão.
• O Gateway inicia e renova o observador sozinho assim que os hooks são ativados e uma conta do Gmail é definida, com uma variável de ambiente para desativar isso. Rode exatamente um: um segundo processo serve ou um comando run manual no mesmo listener gera um conflito de bind, e um listener que iniciou não prova que o watch foi registrado.
• Um lote enviado por push vira uma execução do agente por e-mail, já que o mapeamento se desdobra sobre o array messages, com limite de 200 itens. Os caminhos do Gmail recebem uma cota maior de corpo de requisição, derivada do limite de bytes por mensagem e limitada a 32 MiB, e uma página de histórico do upstream conta registros de histórico, e não e-mails, então um acúmulo ainda pode atingir os limites.

A sessão por mensagem do preset integrado do Gmail separa o contexto da conversa; ela não restringe as ferramentas nem o espaço de trabalho do agente de destino.

Sessões por mensagem não são uma fronteira de permissões

O preset dá a cada mensagem a própria chave de sessão, então o segundo e-mail não consegue ler a conversa do primeiro. Isso é isolamento de contexto, e nada além disso. Se nenhum mapeamento definir um ID de agente, o preset cai no seu agente padrão, o que significa que o e-mail de um desconhecido é resumido pelo agente dono do seu espaço de trabalho e das suas ferramentas. Um mapeamento personalizado que corresponde ao caminho gmail roda antes do preset, e é nele que você nomeia o leitor; a lista de IDs de agente permitidos do hook impede que esse endpoint selecione qualquer outro. Rotear o Gmail para um agente mais capaz é permitido, mas a documentação pede que você trate isso como uma decisão de segurança: wrapping ativado, execução em sandbox, nada concedido além do que o fluxo de trabalho precisa.

O agente mail_reader

• O leitor é uma segunda entrada na lista de agentes, com espaço de trabalho e modelo próprios, e uma sandbox configurada com o modo all, o escopo session e sem acesso ao espaço de trabalho. Assim, cada e-mail ganha uma sandbox nova que não consegue alcançar o espaço de trabalho do agente host, e a execução é descartável por construção.
• A política de ferramentas dele é o perfil minimal com uma única ferramenta permitida, session_status, mais uma lista de bloqueio explícita que cobre os grupos de sistema de arquivos, runtime e web e as ferramentas browser, cron, gateway e nodes. Essa lista de permissões por agente é um limite absoluto, então um acréscimo global via also-allow não consegue vazar para o leitor, e os bloqueios explícitos mantêm a fronteira pretendida auditável.
• Adicionar o leitor transforma a lista de agentes em uma frota explícita, então cada canal que o seu agente principal ainda controla precisa do próprio vínculo, um por canal, porque não existe curinga entre canais. Listar os agentes com os vínculos antes de reiniciar é a verificação que pega um canal sem dono, e a entrega fica desativada, então as conclusões são registradas em log em vez de anunciadas.

Uma regra pega muita gente de surpresa: as políticas de ferramentas só se estreitam à medida que as camadas global, de provedor, de agente e de sandbox se combinam, então a lista de permissões do leitor não consegue restaurar session_status se uma camada anterior o removeu, e um conjunto efetivo de ferramentas vazio aborta a execução antes que o modelo veja o e-mail. Valide o leitor antes de conectar o e-mail: autentique o provedor dele, teste o modelo com o leitor selecionado e, depois, envie um turno de uma linha e exija de volta a resposta exata, a única verificação que exercita juntos o modelo, o runtime, a sandbox e a política de ferramentas. O guia de sandbox do OpenClaw cobre o isolamento em que esse leitor se apoia, e o guia de frotas multiagente do OpenClaw explica as regras de lista de agentes e de vínculos que você acabou de mudar.

Dois tokens, a configuração do gcloud e o teste de fronteira

O comando de configuração do Gmail grava o bloco de transporte, ativa o preset, preserva o mapeamento restrito que você aplicou antes e usa o Tailscale Funnel por padrão para o endpoint de push; o modo serve é restrito à tailnet e não é um destino do Pub/Sub acessível publicamente, então uma URL gerenciada externamente entra com o túnel desligado e o endpoint passado explicitamente. Dois tokens protegem dois saltos: o token de push autentica o Pub/Sub no observador, o token do hook autentica o observador no OpenClaw por um cabeçalho, e tokens na query string são rejeitados, então aquela URL de push que carrega um token não é um modelo para você chamar o caminho do hook por conta própria. A saída da configuração pode mostrar os dois tokens, então oculte-os antes de compartilhá-la. O caminho manual é curto: selecione o projeto dono do cliente OAuth do gog, ative as APIs do Gmail e do Pub/Sub, crie o tópico, conceda à conta de serviço de push do Gmail o papel de publicador e, depois, inicie o watch nesse tópico, o que não registra nenhuma assinatura de push e não inicia nenhum listener. Depois, teste. Envie para você mesmo, de outra conta, uma instrução inerte (a documentação sugere mandar o agente seguir um link e executar um comando) e leia a execução. Um sucesso do observador confirma o transporte, um 200 do hook com um ID de execução registra a admissão, e qualquer tentativa de navegar até um link, gravar um arquivo, executar um comando de shell, agir no navegador ou registrar um MCP é uma verificação de fronteira que falhou. A injeção de prompt no OpenClaw é o modelo de ameaça por trás de tudo isso, e o gatilho de e-mail via IMAP é o mesmo padrão de leitor fora do Google.

Na Diali

A Diali hospeda o OpenClaw como serviço gerenciado, e cada cliente roda o próprio assistente, e não um lugar em um assistente compartilhado. A configuração do runtime é gerada a partir das configurações do seu painel e reescrita a cada versão, enquanto sessões, memória e arquivos do espaço de trabalho ficam em um volume persistente, com snapshots diários e restauração com um clique disponíveis pelo complemento Backups (incluído no Max). Um endpoint de push acessível publicamente é a peça que você precisa combinar conosco, já que o ingress na frente do seu assistente é nosso. O OpenClaw hospedado na Diali descreve o assistente hospedado, e a página de preços da Diali lista o que cada plano inclui.

• O preset separa o contexto, nunca as permissões.
• Dois tokens, dois saltos, nenhuma substituição.
• Um 200 do hook é admissão, não um resumo.