Activar OpenClaw desde Gmail

Quieres que el asistente reaccione cuando llega un correo: una factura nueva, una solicitud de soporte, un aviso de despliegue fallido. El cableado obvio, apuntar Gmail al agente con el que ya chateas, le da a cualquier desconocido que sepa tu dirección un turno en un agente que tiene tu shell, tus archivos y tu navegador. La vía de Gmail de OpenClaw existe para evitar eso, y es una cadena de piezas más que un interruptor.

Cómo llega un mensaje de Gmail a un agente

• Google Pub/Sub es el transporte. Una vigilancia de Gmail sobre una etiqueta publica los eventos de la bandeja de entrada en un tema, Pub/Sub los envía al proceso gog gmail watch serve, y ese vigilante reenvía los datos del correo al hook HTTP del Gateway. Nunca carga un controlador HOOK.md interno: este es el hook externo entrante, no el sistema de eventos dentro del proceso.
• Los requisitos son concretos: la CLI de gcloud, gog autorizado para la cuenta de Gmail vigilada, los hooks activados en OpenClaw, un endpoint push HTTPS al que Pub/Sub pueda llegar de verdad (Tailscale Funnel en la configuración recomendada) y un backend de entorno aislado que funcione, cuya imagen construyes antes de la primera ejecución si te quedas con el backend Docker predeterminado.
• El Gateway inicia y renueva el vigilante por sí mismo en cuanto los hooks están activados y hay una cuenta de Gmail definida, con una variable de entorno para desactivarlo. Ejecuta exactamente uno: un segundo proceso serve o un comando run manual en el mismo listener es un conflicto de enlace, y que un listener haya arrancado no prueba que la vigilancia se haya registrado.
• Un lote enviado se convierte en una ejecución del agente por correo, ya que el mapeo se reparte sobre el array de mensajes, con un máximo de 200 elementos. Las rutas de Gmail reciben un margen mayor para el cuerpo de la solicitud, derivado del límite de bytes por mensaje y con un máximo de 32 MiB, y una página del historial de origen cuenta registros del historial, no correos, así que una acumulación de pendientes aún puede alcanzar los límites.

La sesión por mensaje del preajuste integrado de Gmail separa el contexto de la conversación; no restringe las herramientas ni el espacio de trabajo del agente de destino.

Las sesiones por mensaje no son un límite de permisos

El preajuste da a cada mensaje su propia clave de sesión, así que el segundo correo no puede leer la conversación del primero. Eso es aislamiento de contexto, y nada más. Si ningún mapeo define un id de agente, el preajuste recurre a tu agente predeterminado, lo que significa que el correo de un desconocido lo resume el agente que posee tu espacio de trabajo y tus herramientas. Un mapeo personalizado que coincida con la ruta gmail se ejecuta antes que el preajuste, y ahí es donde nombras al lector, y la lista de ids de agente permitidos del hook impide que ese endpoint seleccione cualquier otro. Enrutar Gmail a un agente con más capacidades está permitido, pero la documentación te pide que lo trates como una decisión de seguridad: encapsulado de contenido activado, ejecución en entorno aislado y nada concedido más allá de lo que necesita el flujo de trabajo.

El agente mail_reader

• El lector es una segunda entrada de la lista de agentes con su propio espacio de trabajo y su propio modelo, y un entorno aislado con el modo all, el alcance session y sin acceso al espacio de trabajo. Así, cada correo obtiene un entorno aislado nuevo que no puede llegar al espacio de trabajo del agente anfitrión, y la ejecución es desechable por construcción.
• Su política de herramientas es el perfil minimal con una sola herramienta permitida, session_status, más una lista de denegación explícita que cubre los grupos de sistema de archivos, runtime y web y las herramientas browser, cron, gateway y nodes. Esa lista de permitidos por agente es un límite absoluto, así que una adición global de also-allow no puede filtrarse hasta el lector, y las denegaciones explícitas mantienen auditable el límite previsto.
• Añadir el lector convierte la lista de agentes en una flota explícita, así que cada canal que tu agente principal siga poseyendo necesita su propia vinculación, una por canal, porque no hay comodín entre canales. Listar los agentes con sus vinculaciones antes de reiniciar es la comprobación que detecta un canal sin propietario, y la entrega está desactivada, así que las finalizaciones se registran en los logs en lugar de anunciarse.

Hay una regla que pilla a la gente desprevenida: las políticas de herramientas solo se estrechan a medida que se combinan las capas global, de proveedor, de agente y de entorno aislado, así que la lista de permitidos del lector no puede restaurar session_status si una capa anterior lo eliminó, y un conjunto efectivo de herramientas vacío aborta la ejecución antes de que el modelo vea el correo. Prueba el lector antes de conectar el correo: autentica su proveedor, sondea el modelo con el lector seleccionado y luego envía un turno de una línea y exige que te devuelva la respuesta exacta, la única comprobación que ejercita a la vez el modelo, el runtime, el entorno aislado y la política de herramientas. La guía del entorno aislado de OpenClaw cubre el aislamiento en el que se apoya este lector, y la guía de flotas multiagente de OpenClaw explica las reglas de la lista de agentes y de vinculación que acabas de cambiar.

Dos tokens, la configuración de gcloud y la prueba de límites

El comando de configuración de Gmail escribe el bloque de transporte, activa el preajuste, conserva el mapeo restringido que aplicaste primero y usa Tailscale Funnel por defecto para el endpoint push; el modo serve es solo para el tailnet y no es un destino de Pub/Sub accesible públicamente, así que una URL gestionada externamente se configura con el túnel desactivado y el endpoint indicado explícitamente. Dos tokens protegen dos saltos: el token push autentica a Pub/Sub ante el vigilante, el token del hook autentica al vigilante ante OpenClaw mediante una cabecera, y los tokens en la query string se rechazan, así que esa URL push que lleva el token no es una plantilla para llamar tú mismo a la ruta del hook. La salida de la configuración puede imprimir ambos tokens, así que elimínalos antes de compartirla. La vía manual es corta: selecciona el proyecto propietario del cliente OAuth de gog, activa las API de Gmail y Pub/Sub, crea el tema, concede el rol de publicador a la cuenta de servicio de push de Gmail y después inicia la vigilancia sobre ese tema, lo que no registra ninguna suscripción push ni inicia ningún listener. Después, prueba. Envíate una instrucción inerte desde otra cuenta (la documentación sugiere decirle al agente que siga un enlace y ejecute un comando) y lee la ejecución. Un éxito del vigilante confirma el transporte, un 200 del hook con un id de ejecución registra la admisión, y cualquier intento de navegar a un enlace, escribir un archivo, ejecutar un comando de shell, realizar una acción en el navegador o registrar un MCP es una comprobación de límites fallida. La inyección de prompts en OpenClaw es el modelo de amenazas detrás de todo esto, y el disparador de correo IMAP es el mismo patrón de lector fuera de Google.

En Diali

Diali aloja OpenClaw como servicio gestionado, y cada cliente ejecuta su propio asistente en lugar de un puesto en uno compartido. La configuración del runtime se genera a partir de los ajustes de tu panel y se vuelve a escribir en cada versión, mientras que las sesiones, la memoria y los archivos del espacio de trabajo viven en un volumen persistente, con instantáneas diarias y restauración con un clic disponibles con el complemento Copias de seguridad (incluido en Max). Un endpoint push accesible públicamente es la pieza que tienes que acordar con nosotros, ya que el ingress delante de tu asistente es nuestro. OpenClaw alojado en Diali describe el asistente alojado, y la página de precios de Diali enumera lo que incluye cada plan.

• El preajuste separa el contexto, nunca los permisos.
• Dos tokens, dos saltos, sin sustituciones.
• Un 200 del hook es admisión, no un resumen.