Tiempo de lectura: 7 minutos
TL;DR
Le pedí a OpenClaw que se actualizara solo. Lo hizo. Después, el gateway se negó a arrancar porque un campo de configuración había cambiado de forma silenciosa entre versiones (channels.discord.streaming pasó de ser una cadena a ser un objeto). openclaw doctor --fix detectó el problema, pero no fue capaz de arreglarlo. El AI Overview de Google sugirió con total seguridad lo contrario de la solución correcta. Hermes-Agent, con acceso a shell y al sistema de ficheros, leyó la configuración rota, hizo el único cambio necesario, guardó una copia de seguridad del original, reinició el servicio y verificó que todo iba bien, todo a partir de un prompt de un único párrafo. Trece minutos desde el primer aviso en rojo hasta el verde. Esto es lo que realmente significa «agentic ops».
Llevo bastante tiempo ejecutando OpenClaw en una Raspberry Pi 5. Es ese tipo de montaje que afinas los fines de semana y olvidas durante la semana, hasta que llega una actualización y algo se rompe sin avisar.
Esta mañana fue una de esas mañanas. Lo que quiero dejar por escrito no es solo el bug, sino la forma del arreglo. La herramienta de reparación de OpenClaw no fue lo que devolvió el gateway a la vida. Tampoco lo fue el AI Overview que aparece en la parte superior de cada resultado de Google. Lo que funcionó fue un agente de propósito general con acceso a shell y a ficheros, y la costumbre de leer una configuración antes de tener una opinión sobre ella.
Esa distinción parece pequeña. No lo es.
Paso 1: Le Pedí a AgentX que se Actualizara
Toda la historia empieza con una instrucción perfectamente razonable. Abrí la interfaz de chat de OpenClaw, saludé a AgentX (mi agente principal de OpenClaw) y le pedí que se actualizara.
update yourself please. El tipo de frase que le dices a un agente autónomo dando por hecho que sabrá apañárselas.
Y la parte de la actualización la gestionó. Lo que no gestionó fue la parte de validación posterior a la actualización, porque eso todavía no es algo que OpenClaw haga por sí mismo. La nueva versión introducía un cambio de esquema en uno de los campos de configuración. La actualización escribió los nuevos binarios. El fichero de configuración mantuvo su forma antigua. El siguiente arranque del gateway iba a fallar.
Yo todavía no sabía nada de esto.
Paso 2: Media Hora Después, el Gateway se Niega a Arrancar
Misma sesión, misma mañana. La actualización terminó en silencio en segundo plano. Cuando fui a levantar el gateway — openclaw gateway, esperando un arranque normal —, esto fue lo que obtuve:
Invalid config at /home/vulnex/.openclaw/openclaw.json:
channels.discord.streaming: invalid config: must be object
Run "openclaw doctor --fix" to repair, then retry.
Útil, en teoría. El arranque deja escrito un stability bundle (bien — para eso están los stability bundles) y el servicio se cae justo después.
Paso 3: El Status Confirma el Estado Roto
Lancé openclaw gateway status para ver el cuadro completo.
Una línea roja de lado a lado. state failed, sub failed, last exit 1, reason 1. La URL del dashboard ahí, burlándose de mí, la sonda de loopback sin poder conectar, y el gateway sin intención de volver por su cuenta.
En un mundo normal, este es el momento en el que sigues la solución sugerida por OpenClaw y terminas en cinco minutos. Eso fue lo primero que probé.
Paso 4: doctor --fix — La Auto-Reparación Que No Fue (Parte 1)
openclaw doctor --fix se supone que es el botón de «¿has probado a apagarlo y volverlo a encender?». Así que lo ejecuté.
El doctor se dedicó a sermonearme sobre NODE_COMPILE_CACHE y OPENCLAW_NO_RESPAWN en hosts de poca potencia. Consejos útiles. No el problema.
Paso 5: doctor --fix — La Auto-Reparación Que No Fue (Parte 2)
El doctor recorrió las secciones de config y gateway y acabó donde yo había empezado:
Restarted systemd service: openclaw-gateway.service
Error: Config validation failed: channels.discord.streaming: invalid config: must be object
El doctor reinició el servicio, pero nunca llegó a tocar la clave problemática. Lo cual tiene sentido, visto en frío. El validador dice «must be object», pero el doctor no tiene ninguna opinión sobre qué forma concreta debería tener ese objeto. No está en el negocio de adivinar esquemas nuevos. Es una postura razonable. Tampoco es muy útil a las 10:27 de la mañana.
Una cosa que OpenClaw debería cambiar: doctor --fix no debería imprimir «Restarted systemd service» una línea por encima de «Error: Config validation failed» y salir tan contento. A mí me confundió, y va a confundir a más gente. Lo abriré como bug.
Paso 6: La Respuesta Equivocada del AI Overview
Llegado este punto hice lo que haría la mayoría de la gente: pegué el mensaje de error exacto en Google a ver si alguien más se había topado con esto entre versiones.
Me decía que el validador quiere una cadena como "partial" y que mi configuración tenía un objeto, cuando en realidad el nuevo OpenClaw espera un objeto y mi configuración antigua tenía una cadena. Incluso me ofrecía un bloque JSON limpio, con resaltado de sintaxis, listo para copiar y pegar directamente en el fichero para romperlo más, etiquetado con un pin de citación de GitHub que daba toda la confianza del mundo.
Si hubiera ido con prisa, lo habría pegado. Esa es la parte que las demos de «IA para ops» suelen pasar por alto sin hacer ruido. La respuesta era fluida, estaba bien formateada, hasta llevaba cita, y apuntaba justo en sentido contrario a la dirección real de la migración del esquema.
Es el mismo modelo de amenaza que cubrí en Professional Vibe Coding vs. Vibe Coding, trasladado de un contexto de código a uno de operaciones. Si tu IA no puede leer el validador ni la configuración, te va a dar una respuesta segura sintetizada a partir del texto del error, y a veces esa respuesta es justo la contraria a la correcta.
Paso 7: Entra Hermes
Tengo Hermes-Agent enganchado a esta máquina precisamente para este tipo de líos. Trae herramientas de fichero, ejecución de shell, y la paciencia de leer las cosas en lugar de adivinarlas.
El stack de skills aquí importa: file:patch, read_file, search_files, write_file, code_execution, además del skill openclaw-agent-integrations que mantengo en local justo para este tipo de fontanería. Nada glamuroso, solo los movimientos básicos que hacen falta para arreglar un servicio mal configurado.
Le di un brief de un párrafo:
«I told openclaw to update itself and did, however the latest version breaks due a openclaw config json file error. The folder path is /home/vulnex/.openclaw. Make a copy of the config json file and fix the issue. You can use openclaw command to see the issue.»
Eso es todo. Sin esquema, sin pistas, sin ejemplo del nuevo formato.
Paso 8: Hermes se Orienta
Hermes hizo lo que yo habría hecho si hubiera dispuesto de otra hora.
- Inspeccionó el entorno
- Encontró la manera de invocar
openclaw(el binario está en miPATH, pero la shell no interactiva de Hermes no lo heredó, así que tiró denpx --yes openclawy lo dejó claro en su resumen) - Leyó la configuración rota
- Recuperó el stability bundle que el gateway había dejado caer al desplomarse
Nada de una única llamada dramática al LLM. Una pila de pasos pequeños y verificables: find, command -v, head, npm prefix -g, un heredoc de python3 que recorre $PATH buscando cualquier cosa que contenga claw. Aburrido a propósito.
Paso 9: Hermes Diagnostica
Una vez que tenía la configuración y el stability bundle en contexto, Hermes los comparó y averiguó qué había cambiado exactamente entre versiones.
Nada de adivinar a partir del texto del error. Lectura del original.
Paso 10: El Arreglo Aterriza
Hermes no tuvo el problema que tuvo el AI Overview, porque Hermes estaba leyendo los ficheros reales en lugar de inferir desde la prosa del error.
El diff es la historia completa:
// antes — forma antigua, válida en 2026.5.18 y anteriores
"channels": {
"discord": {
"streaming": "off"
}
}
// después — forma nueva, requerida en 2026.5.19
"channels": {
"discord": {
"streaming": { "mode": "off" }
}
}OpenClaw 2026.5.19 promovió channels.discord.streaming de cadena a objeto etiquetado. El doctor vio que algo estaba mal, pero no tenía opinión sobre la nueva forma. El AI Overview de Google sí tenía opinión, y era la contraria a la correcta. Hermes:
- Leyó la configuración rota y el stability bundle
startup_failed.jsondel gateway - Hizo el cambio mínimo posible
- Escribió
~/.openclaw/openclaw.json.agenth-bak-20260521-103255junto al original - Reinició el servicio del gateway
- Verificó que el JSON parsea bien y que el error anterior había desaparecido
También fue honesto con sus propias matizaciones:
- Usó
npx --yes openclawporque su shell no interactiva no heredó miPATHinteractivo — aunque el binarioopenclawestá, de hecho, instalado globalmente en este host. Una pequeña lectura errónea del entorno, pero transparente. openclaw doctorseguía reportando avisos no relacionados, pero el problema de arranque que rompía la configuración estaba resuelto.
Esa auto-declaración importa, incluso cuando (como en el caso del PATH) el agente es algo demasiado pesimista sobre su entorno. Es mucho más fácil confiar en un agente que pone sus supuestos encima de la mesa que en uno que los esconde.
Paso 11: Verificación Desde el Shell
Confía, pero verifica. Vuelta al comando original que arrancó toda esta historia.
Runtime: running (pid 10178, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Mismo comando, resultado opuesto. Once minutos antes esto había sido un muro rojo.
Paso 12: Pedirle a AgentX que lo Confirme
Después volví a la interfaz de chat de OpenClaw, el mismo sitio donde había empezado toda la historia, y se lo pregunté directamente a AgentX. Porque si no puedes fiarte de que el agente te cuente su propio estado tras una recuperación, tienes otros problemas.
«All good — gateway is running on 2026.5.19, active since 10:33. The
doctor --fixrestart attempt errored but the service came up fine on its own. We’re fully updated and online.»
Trece minutos desde el primer aviso en rojo hasta tenerlo en verde. La mayor parte de ese tiempo me lo pasé leyendo yo.
La sesión de chat hace de marco para toda la historia. Se abre con «update yourself please» y se cierra con «fully updated and online». Entremedias, un agente completamente distinto tuvo que entrar a hacer el trabajo real. Ese hueco es de lo que va este artículo.
Qué Nos Dice Realmente Este Episodio
La versión bonita de la historia es «agente que se rompe a sí mismo, agente que se arregla a sí mismo». Lo interesante está en el medio.
La herramienta de reparación del propio fabricante no arregló el producto del propio fabricante
openclaw doctor --fix es una buena idea ejecutada a medias. O entiende los caminos de migración de esquemas entre versiones recientes, o deja de fingir que ha hecho una reparación cuando la siguiente línea de su propio output dice que la configuración sigue sin validar. Ahora mismo hace lo peor posible: canta victoria y te deja roto. Eso es un bug de OpenClaw, no de la IA, y lo voy a reportar.
Los AI Overviews para usuario final se equivocan con seguridad en preguntas de esquema
Esto no es un caso aislado. El AI Overview no puede leer tu configuración, no puede leer el código del validador, no puede decirte hacia dónde ha migrado un esquema entre dos versiones, y formatea la respuesta equivocada con la misma seguridad que la correcta.
Para alguien que solo intenta levantar el gateway antes de una reunión, esa respuesta es peor que ninguna respuesta. Ninguna respuesta te manda a la documentación. Una respuesta equivocada con aire de seguridad te manda a pegar JSON roto en un fichero que estaba bien.
Tampoco es un problema específico de Google. Es el patrón general de producir una respuesta fluida a partir del síntoma en lugar de la fuente. Cualquier IA desplegada sin acceso de lectura al artefacto real se va a chocar con el mismo muro.
El agente que sí funcionó no era magia
Hermes no resolvió esto por ser más grande, más inteligente o estar entrenado con algo exótico. Lo resolvió porque podía leer el fichero, ejecutar un comando, escribir el fichero, y guardar una copia de seguridad. Esos cuatro movimientos son el suelo de lo que yo llamaría agentic ops, y la mayoría de la IA para usuario final sigue claramente por debajo de ese suelo.
La regla que me llevo de esta mañana es corta: si la IA en la que estás a punto de confiar para tocar una configuración no puede leer el fichero ni guardar una copia, no es una herramienta de ops. Es un buscador con mejor gramática.
Qué Voy a Cambiar en Mi Setup Después de Esto
Algunas cosas que voy a montar este fin de semana.
Quiero que ~/.openclaw/openclaw.json quede capturado en un repo git local antes de cada openclaw update. Los ficheros .agenth-bak de Hermes están bien para un incidente puntual, pero un historial real con control de versiones es mejor cuando llegue el próximo cambio de esquema.
También voy a dejar de tratar doctor --fix como una recuperación de un solo paso. Es un diagnóstico que de vez en cuando además escribe un arreglo. La auténtica verificación tiene que ser volver a lanzar openclaw gateway status y leer la salida.
Hermes se queda enganchado a esta máquina con scopes de fichero y ejecución pre-aprobados. La gracia del montaje es que cuando algo se rompe a las 10:25, no estoy también a las 10:26 cableando permisos de herramientas.
Y los nombres de los backups necesitan trabajo. openclaw.json.agenth-bak-20260521-103255 es razonable, pero quiero que esos ficheros caigan en ~/.openclaw/backups/ en lugar de quedarse al lado de la configuración viva.
Si estás ejecutando OpenClaw, la Guía Sencilla de Hardening de Seguridad para OpenClaw que escribí esta primavera sigue siendo la línea base correcta. Nada en el incidente de esta mañana cambia esas recomendaciones. Solo refuerza por qué una IA de solo lectura, que no puede tocar el artefacto, no debería estar en ningún punto cercano a tu bucle de recuperación.
Notas del Setup
Para quien quiera reproducir o comparar:
- OpenClaw 2026.5.19 sobre un host Linux de clase Raspberry
- Gateway en el puerto
18789, controlado desde la interfaz web de OpenClaw - Hermes-Agent v0.12.0 sobre el backend
gpt-5.5con 272K de contexto, configurado contra mi stack de skills estándar - El
~/.openclaw/openclaw.jsonoriginal conservado comoopenclaw.json.agenth-bak-20260521-103255para comparación forense
Una línea de JSON, y un recordatorio: la IA en la que confías durante un incidente tiene que poder leer el fichero.
Mantente paranoico. Lee la fuente. Guarda el backup.
- X (Twitter): @SimonRoses
Lecturas Recomendadas:
- Mi Experiencia Usando OpenClaw: El Viaje de un Profesional de Seguridad
- Guía Sencilla de Hardening de Seguridad para OpenClaw
- Professional Vibe Coding vs. Vibe Coding
- La IA Debe Crear Superhumanos, No Desempleados
- Hermes-Agent (Nous Research)
- Documentación de OpenClaw
¿Preguntas o feedback? Contáctame a través de:
- Web: vulnex.com
- Twitter/X: @SimonRoses
- LinkedIn: linkedin.com/in/simonroses
- GitHub: github.com/vulnex
¿Necesitas ayuda para fortificar tu despliegue de agentes de IA? VULNEX ofrece:
- Auditorías de seguridad de agentes IA (auditoría de skills, pruebas de prompt injection, revisión de configuración)
- Engagements de red team (simulaciones de ataque potenciadas por IA)
- Consultoría de automatización de seguridad y agentic ops
- Desarrollo a medida de herramientas de seguridad
Contacto: info@vulnex.com
