[NOVA]: Esto es OpenClaw Daily. Soy NOVA.

[ALLOY]: Y soy ALLOY. Hoy empezamos con OpenClaw v2026.5.7, porque este lanzamiento cambia cómo los operadores ven la publicación, el estado de cron, la configuración de canales, la autorización, la entrega, la voz, el enrutamiento de WhatsApp y las aprobaciones de Codex antes de pasar a los sandbox de agentes JavaScript y el endurecimiento del runtime de Gemini CLI. ...

[NOVA]: El lanzamiento les da a los operadores nuevas formas de ver si la publicación, cron, canales, autenticación, entrega, voz, memoria y aprobaciones realmente se están comportando. ClawHub publishing ahora reintenta fallos transitorios de instalación de dependencias, mantiene que los plugins que pasan la vista previa siganpublicándose cuando una celda de vista previa falla, y verifica cada versión de paquete esperada después de publicar. Cron JSON ahora expone el estado calculado directamente. El listado de canales se enfoca en canales en lugar de mezclar detalles de autenticación del modelo. El dispatch de skills inline de auto-reply ahora pasa por los hooks de autorización antes de la llamada de herramienta. Las herramientas de Tavily resuelven credenciales respaldadas por SecretRef desde la snapshot de configuración del runtime activo. Los objetivos de canal de Discord con prefijo de proveedor se enrutan como envíos de canal en lugar de intentos engañosos de mensaje directo. Esa es la forma del lanzamiento: menos suposiciones ocultas, menos cachés obsoletos, menos falsos éxitos, y más contratos explícitos para operadores.

[ALLOY]: OpenClaw v2026.5.7 Hace que la Publicación, Canales, Cron, Auth, Memoria, Entrega, Voz, WhatsApp y Aprobaciones de Codex Sean Más Observables y Seguras Empecemos con la publicación del release y plugins. Un lanzamiento de mantenimiento no debería dejar a los operadores preguntándose si un plugin realmente se publicó en todas partes donde se supposedía que debía llegar. v2026.5.7 añade manejo de reintentos para fallos transitorios de instalación de dependencias de ClawHub CLI, mantiene que un plugin sea publicable cuando una celda de vista previa falla aunque la vista previa pasó, y verifica cada versión de paquete de ClawHub esperada después de publicar. Ese paso final de verificación es el importante. Un pipeline de publicación no está completo cuando un comando sale; está completo cuando las versiones de paquete esperadas son visibles donde los instaladores posteriores las van a obtener.

[NOVA]: Eso importa para un ecosistema de plugins porque las publicaciones parciales son peores que los fallos limpios. Un paquete puede estar disponible en un lugar, faltar en otro, o publicado con la versión incorrecta. Los operadores entonces persiguen errores de instalación que parecen problemas de configuración local pero en realidad son problemas de distribución del release. La verificación post-publicación convierte el proceso de release en un loop de reconciliación: declara el conjunto de paquetes esperado, intenta la publicación, y verifica que el estado del registro coincida. Si no coincide, el fallo es visible en el momento del mantenimiento en lugar de ser descubierto por los usuarios.

[ALLOY]: La superficie del modelo de OpenAI recibe una adición específica: openai/chat-latest es soportado como una anulación explícita de modelo de API key directa para probar el alias móvil de ChatGPT Instant API sin cambiar el modelo predeterminado estable. La frase clave es anulación explícita. Un alias móvil es útil para probar comportamiento del lane de chat instantáneo actual, pero es un mal predeterminado para agentes de producción porque su snapshot de modelo subyacente puede cambiar. Mantenerlo detrás de un ID de modelo explícito permite que los builders prueben el alias mientras preservan los predeterminados estables para trabajos programados, flujos de trabajo de producción y evaluaciones reproducibles.

[NOVA]: Cron se vuelve más fácil de automatizar. cron list --json y cron show --json ahora incluyen el estado calculado, así que las herramientas externas pueden leer el estado disabled, running, ok, error, skipped o idle sin reimplementar la derivación de estado de OpenClaw. Este es un buen cambio de contrato de API. Si una CLI le da a las máquinas JSON, el JSON debería incluir el estado que los humanos ven. De lo contrario, cada dashboard, monitor y script wrapper tiene que reverse-engineering del estado a partir de timestamps, campos de último error, flags de enable y marcadores de ejecución. Eso crea automatización inconsistente y falsas alarmas.

[ALLOY]: La inspección de canales también obtiene un contrato más limpio. openclaw channels list ahora es solo canales, añade --all para canales bundled y catalog, renderiza los estados installed, configured y enabled, y mueve los detalles de autenticación de modelo y uso a openclaw models auth list, openclaw status y openclaw models list. La separación es importante porque la preparación del canal y la autenticación del modelo son diferentes dominios operacionales. Un canal de Slack o Discord puede estar instalado pero deshabilitado, configurado pero sin permisos, o habilitado pero no actualmente sano. La autenticación de modelo pertenece a las credenciales del proveedor y la selección del runtime. Mezclar eso en un comando hace que sea más difícil para la automatización responder preguntas simples.

[NOVA]: Los límites de seguridad se estrechan en varios lugares. Los manejadores de comandos nativos ahora respetan el cumplimiento de owner. Active Memory requiere scope de admin para los toggles de memoria global. Auto-reply controla el dispatch de herramientas de skills inline a través de hooks de autorización before-tool-call. Esos son todos arreglos de autorización alrededor de superficies que pueden cambiar el estado del sistema. Los comandos nativos pueden ejecutar rutas de control privilegiadas. Los toggles de memoria global pueden afectar lo que las sesiones futuras recuerdan. Los skills inline pueden activar herramientas desde una ruta de auto-reply, donde el usuario puede no estar observando cada paso interno. El lanzamiento empuja estas acciones de vuelta a través de verificaciones de autorización explícitas.

[ALLOY]: El arreglo de dispatch de skill inline merece ser destacado. Los sistemas de skills son convenientes porque permiten que un agente enrute una tarea a comportamiento empaquetado. Pero si auto-reply puede dispatchar una herramienta de skill inline sin pasar por la autorización before-tool-call, entonces la ruta conveniente se convierte en la ruta más débil. El diseño correcto es que cada punto de entrada de herramienta, ya sea invocado por un turno de chat visible, un skill inline, un plugin, o un auto-reply en background, fluya a través del mismo policy hook antes de la ejecución. Eso le da a los administradores un lugar para implementar comportamiento de allow, deny, prompt, log o rate-limit.

[NOVA]: Las credenciales reciben un arreglo similar de límite de runtime. Las herramientas dedicadas tavily_search y tavily_extract ahora resuelven credenciales desde la snapshot de configuración del runtime activo, así las API keys exec SecretRef-backed no llegan a las herramientas sin resolver. Los sistemas SecretRef solo funcionan si cada herramienta lee secretos a través de la misma vista de runtime resuelta. Si una herramienta recibe el marcador literal sin resolver, el fallo parece credenciales malas aunque el secreto exista. Peor aún, los desarrolladores pueden trabajar alrededor de eso hardcodeando una clave. Resolver desde la snapshot activa mantiene la configuración por ejecución, SecretRefs y credenciales de herramientas alineadas.

[ALLOY]: Las rutas de instalación de plugins administrados se vuelven más robustas también. OpenClaw ahora usa el mismo shell npm lifecycle POSIX absoluto para operaciones npm de instalación, rollback, reparación y desinstalación de plugins administrados como actualizaciones de paquetes staged. El modo de fallo aquí es sutil: un shell PATH restringido puede romper la limpieza o rollback aunque la ruta de instalación original funcione. Usar el mismo shell lifecycle absoluto a través de las acciones de instalación y reparación reduce la deriva del entorno. Los operadores deberían poder confiar en que rollback usa las mismas suposiciones de toolchain que instalación.

[NOVA]: La corrección de sesión y contexto recibe atención. Las sesiones del gateway limpian las snapshots de skills en caché durante /new y sessions.reset, así que las sesiones de canales de larga duración reconstruyen las listas de skills visibles después de que los skills cambian. Los motores de contexto del agente invalidan las vistas de contexto ensambladas en caché cuando el historial fuente se encoge o el ensamblaje falla, previniendo que el historial pre-reset obsoleto sea reutilizado. Estos son bugs de invalidación de caché, pero el impacto visible para el usuario es severo. Si un reset no limpia la snapshot de skills, el agente puede anunciar capacidades obsoletas. Si una vista de contexto sobrevive a un encogimiento del historial, el modelo puede ver estado de conversación antiguo después de un reset.

[ALLOY]: La compactación obtiene un guard de límite de modelo. Los tokens de reserva de resumen se limitan al límite de salida de cada modelo para que la compactación de alto contexto ya no solicite valores max_tokens inválidos. Este es un problema práctico multi-modelo. Un motor de contexto puede planear una reserva de resumen grande, pero el modelo seleccionado puede no ser capaz de emitir tantos tokens. Si la solicitud se envía de todos modos, la compactación falla en el límite del proveedor. Limitar los tokens de reserva a los límites de salida del modelo convierte una solicitud inválida en un plan de resumen acotado.

[NOVA]: La semántica de entrega se vuelve más honesta. La entrega del agente ahora reporta deliverySucceeded=false cuando la entrega outbound no devuelve resultado de adaptador, así que las rutas de entrega reclamadas o vacías ya no se disfrazan como envíos exitosos. Las ejecuciones aisladas de cron también fallan la entrega implícita de announce antes de la ejecución del modelo cuando delivery.channel=last no tiene ruta previa, así que los trabajos recurrentes no gastan tokens antes de golpear un error de objetivo de entrega permanente. Ambos cambios siguen el mismo principio: no ejecutes trabajo costoso si la ruta de salida es imposible, y no reportes éxito cuando ningún adaptador confirmó la entrega.

[ALLOY]: El parsing de objetivos de Discord obtiene un arreglo concreto para mensajería de agente entre canales. Los objetivos con prefijo de proveedor como discord:channel:<id> ahora se parsean como envíos de canal en lugar de objetivos legados de mensaje directo de Discord. Esto previene que las llamadas de acción de agente de mensaje(action="send") entre canales mal enruten IDs de canal en fallos engañosos de Unknown Channel. Los namespaces importan aquí. Un objetivo de canal con prefijo de proveedor no es un ID de usuario, y una capa de mensajería genérica debería preservar esa intención hasta el适配器.

[NOVA]: El endurecimiento de Telegram abarca autorización y vitalidad. Telegram ahora respeta las allowlists de accessGroup:* sender para DMs, grupos, comandos nativos y autorización de callback antes de aplicar verificaciones numéricas de ID de remitente. El watchdog de polling permanece atado a la vitalidad de getUpdates así que las llamadas del Bot API outbound no relacionadas no pueden enmascarar un poller inbound atascado. Ese segundo arreglo es un problema clásico de health-check. Un bot todavía puede enviar mensajes mientras su loop de polling inbound está atascado. Si las llamadas outbound reinician el watchdog, el sistema se ve sano aunque no pueda recibir input del usuario.

[ALLOY]: Las operaciones de voz mejoran en Discord. Las capacidades de channels y channels status --probe ahora auditan los permisos de canal de voz de Discord, incluyendo objetivos de auto-join, así que los permisos faltantes de Connect, Speak y Read Message History aparecen antes de /vc join. La captura de voz también es menos entrecortada: el grace de silencio post-speech por defecto se extiende a 2.5 segundos, voice.captureSilenceGraceMs está disponible para sesiones ruidosas, y el prompt de salida hablada se aprieta alrededor de fragmentos STT en vivo. Los agentes de voz viven o mueren por la segmentación de turnos. Muy poco grace de silencio recorta a los hablantes. Demasiado grace hace que el agente sea lento. Hacer el grace configurable le da a los operadores una perilla de ajuste para ruido de habitación y estilo de habla.

[NOVA]: Los arreglos de WhatsApp son operativamente específicos pero importantes. Los envíos proactivos de números de teléfono ahora se enrutan a través de mapeos LID forward de Baileys cuando están disponibles, así que los contactos direccionados por LID reciben mensajes del agente en lugar de crear chats fantasma solo del remitente. Los auto-replies de directivas MEDIA: con leyenda ahora se envían una vez en lugar de emitir un mensaje de medios vacío antes de la respuesta de medios con leyenda. Ambos son ejemplos de corrección de adaptador. Los proveedores de mensajería a menudo tienen múltiples formas de identidad y primitivas de medios. La plataforma del agente necesita mapearlas correctamente o los usuarios ven mensajes duplicados, faltantes o fantasma.

[ALLOY]: El comportamiento de aprobación de Codex cambia de una manera que debería reducir la fatiga de aprobación sin saltarse la revisión. En los modos de aprobación de Codex, OpenClaw deja de instalar el hook nativo de PermissionRequest pre-guardian por defecto, permitiendo que el revisor de Codex apruebe comandos seguros antes de que OpenClaw muestre una aprobación. Recuerda las decisiones de allow-always para payloads idénticos de PermissionRequest nativos de Codex dentro de la ventana de sesión activa, y las solicitudes de aprobación de plugins validan y renderizan sus decisiones allowed actuales para que las UIs de aprobación nativas como Telegram y otras no puedan ofrecer acciones obsoletas. El detalle a explicar es la secuenciación: deja que el revisor interno maneje comandos seguros, muestra aprobaciones cuando sea necesario, y asegúrate de que las acciones de UI coincidan con el conjunto de decisiones allow actuales.

[NOVA]: La compatibilidad de proveedores y medios también recibe correcciones. OpenClaw normaliza las cargas PNG detectadas como APNG, preserva la reproducción de pensamiento-firma de llamadas de herramientas de Gemini 3 con firmas de respaldo, acepta claves legacy __env__:VAR de proveedores personalizados, y repara la sanitización de transcripciones de llamadas de herramientas en snake_case. Estos son los detalles que hacen que las transcripciones y herramientas sean portables. Si las firmas de llamadas de herramientas no se reproducen, el estado del proveedor puede rechazar turnos siguientes. Si la sanitización de transcripciones maneja mal las llamadas en snake_case, las superficies de reproducción y auditoría divergen de lo que realmente ocurrió.

[ALLOY]: La calificación práctica de esta versión es alta para los operadores. v2026.5.7 no es una función llamativa; es un conjunto de contratos de confiabilidad. La publicación verifica el estado del registro. Cron expone el estado calculado. Los canales y la autenticación del modelo están separados. Las habilidades inline pasan por la autorización. SecretRefs se resuelven en tiempo de ejecución. Las cachés de contexto se invalidan después del reinicio. La entrega falla antes de gastar tokens. Los permisos de voz y el tiempo de captura son visibles. Las aprobaciones de Codex se alinean con las decisiones reales. Estos son los cambios que hacen que un sistema de agentes sea menos misterioso cuando funciona todo el día.

[NOVA]: OpenAI Agents JS v0.9 a v0.11 Convierte Sandboxes en Manifiestos de Workspace, Límites de Runtime, Programación de Herramientas y Límites de Artefactos El SDK de Agentes de OpenAI para JavaScript ha avanzado rápido esta semana, y el cambio más importante es la superficie del agente sandbox. Los agentes sandbox se construyen sobre el Agent, Runner y flow existentes, pero agregan workspaces persistentes, manifiestos de workspace, sesiones sandbox, capacidades, snapshots, memoria y soporte de resume. En términos prácticos, esta es la diferencia entre un agente que puede llamar una función y un agente que puede trabajar en un entorno de computadora controlado a lo largo del tiempo.

[ALLOY]: La abstracción central es el Manifiesto. Un manifiesto describe lo que contiene el workspace del agente: archivos y directorios sintéticos, archivos y directorios locales, repositorios Git, variables de entorno, usuarios, grupos, permisos, montajes y ubicaciones de salida. Eso convierte la configuración del sandbox en un contrato de workspace declarativo. En lugar de que una tarea diga "de alguna manera dale a este agente un repo y un lugar para escribir artefactos", el manifiesto dice exactamente qué está montado, dónde aparece, qué archivos son editables y qué rutas externas están permitidas.

[NOVA]: Eso importa porque los agentes de archivos y comandos necesitan límites. Si un agente puede inspeccionar archivos, ejecutar comandos, aplicar parches y generar artefactos, el sandbox tiene que definir qué está dentro del alcance. Un workspace persistente es poderoso para tareas de largo plazo porque el agente puede continuar desde un estado previo, pero la persistencia también significa que el estado puede acumularse. Los snapshots y el comportamiento de resume permiten a los constructores decidir cuándo preservar, restaurar o descartar ese estado. La pregunta operativa se convierte en: ¿cuáles archivos son entradas de la tarea, cuáles son salidas generadas, y cuáles son memoria persistente entre ejecuciones?

[ALLOY]: v0.11.0 agrega un cambio en el límite de artefactos que es fácil de pasar por alto pero importante. La materialización del material fuente local del sandbox ahora mantiene LocalFile.src y LocalDir.src dentro del baseDir de materialización a menos que la ruta fuente esté cubierta por Manifest.extraPathGrants. El directorio base es el directorio de trabajo actual del proceso del SDK cuando se aplica el manifiesto. Las fuentes relativas se resuelven desde ese directorio. Las fuentes absolutas deben estar ya dentro de él o bajo una otorgación explícita. Esto cierra un problema de límite de artefactos locales.

[NOVA]: La implicación de migración es directa. Si una aplicación copia intencionalmente archivos host confiables desde fuera del directorio base hacia un workspace sandbox, ahora tiene que declararlo con una otorgación de ruta extra. Ese es un mejor contrato. Hace la diferencia entre "el agente puede leer rutas host arbitrarias porque una ruta fuente señalaba ahí" y "la aplicación otorgó explícitamente este directorio externo, posiblemente de solo lectura, con una descripción." Para sistemas de agentes que manejan datos de clientes, repositorios propietarios o archivos cercanos a credenciales, las otorgaciones explícitas son el valor predeterminado correcto.

[ALLOY]: El modelo predeterminado del SDK cambió en v0.10.0 de gpt-4.1 a gpt-5.4-mini cuando no se establece ningún modelo. Eso afecta a los agentes y ejecuciones que dependían de valores predeterminados implícitos. Porque el nuevo valor predeterminado es un modelo GPT-5, la configuración predeterminada implícita del modelo ahora incluye valores predeterminados de GPT-5 como reasoning.effort="none" y verbosity="low". La recomendación para constructores es simple: los agentes de producción deben establecer el modelo explícitamente. Los valores predeterminados son útiles para ejemplos y prototipos, pero el comportamiento del agente, costo, latencia, esfuerzo de razonamiento y verbosidad no deberían cambiar solo porque una dependencia fue actualizada.

[NOVA]: Los límites de turnos se vuelven explícitos. maxTurns=null puede deshabilitar el límite de turnos de ejecución del Agents SDK, mientras se deja el valor predeterminado en DEFAULT_MAX_TURNS, actualmente diez, cuando se omite la configuración. Esta es una válvula de seguridad en tiempo de ejecución. Un límite de turnos duro previene bucles descontrolados y costos sorpresa. Deshabilitar el límite puede ser necesario para flujos de trabajo de largo plazo, pero debe combinarse con otros controles: timeouts de reloj de pared, listas de herramientas permitidas, límites de presupuesto, checkpointing y visibilidad del progreso. La distinción útil es que omitido significa valor predeterminado seguro; null significa que el desarrollador intencionalmente removió el límite.

[ALLOY]: La programación de herramientas también se vuelve más controlable. toolExecution.maxFunctionToolConcurrency en RunConfig controla la concurrencia de ejecución de herramientas de función local del lado del SDK. Esto es independiente de provider-side ModelSettings.parallelToolCalls. Esa separación importa. El modelo puede tener permiso para proponer múltiples llamadas de herramientas en paralelo, pero el runtime local todavía necesita decidir cuántas ejecutar a la vez. Una herramienta de sistema de archivos, una herramienta de base de datos, una herramienta de shell y una herramienta HTTP tienen diferentes efectos secundarios y perfiles de recursos. La concurrencia local es una política de programación en tiempo de ejecución, no solo una preferencia de generación del modelo.

[NOVA]: La nominación de herramientas MCP obtiene una opción de evasión de colisiones. El SDK puede incluir el nombre del servidor MCP en los nombres de herramientas, alineándose con el SDK de Python. Esto previene conflictos cuando múltiples servidores MCP exponen herramientas con el mismo nombre local. Sin prefijos de servidor, dos servidores diferentes podrían exponer ambos search, read o query. El agente entonces ve nombres de herramientas ambiguos, y los logs se vuelven más difíciles de auditar. La nominación con prefijo de servidor hace que el espacio de nombres de herramientas sea más explícito, lo cual es especialmente importante cuando los agentes se conectan a múltiples servidores de herramientas internos y externos.

[ALLOY]: v0.11.0 también cambia el modelo predeterminado de RealtimeAgent a gpt-realtime-2. Los valores predeterminados de realtime no son cosméticos. Un modelo realtime afecta la latencia de audio, la toma de turnos, el comportamiento de transcripción, las expectativas de barge-in y la calidad de interacción por voz. Si un producto usa RealtimeAgent sin fijar un modelo, actualizar el SDK puede cambiar el comportamiento realtime subyacente. Una vez más, la recomendación es fijar los valores predeterminados de producción y probar los nuevos modelos realtime bajo condiciones de audio representativas antes de moverlos a sesiones面向cliente.

[NOVA]: La serie de lanzamiento también incluye correcciones que muestran dónde fallan los runtimes de agentes. v0.9.1 preserva la identidad del agente de nombre duplicado en la serialización del estado de ejecución, reconcilia las llamadas de función transmitidas cuando las ejecuciones administradas por el servidor se abortan, y evita reproducir IDs de elementos de conversación del asistente. v0.10.1 restaura el historial de sesión cuando falla la reemplazo de compactación de respuestas y valida las políticas de aprobación de MCP hospedado. Estas son correcciones de máquina de estados. Los sistemas de agentes tienen estado local, estado del servidor, deltas transmitidos, reemplazo de compactación y política de aprobación. Si estos se desincronizan, el siguiente turno puede reproducir el elemento equivocado, perder historial o aprobar la acción equivocada.

[ALLOY]: La conclusión práctica para los constructores de JavaScript es tratar el Agents SDK como un runtime, no solo como un envoltorio alrededor de llamadas de modelo. Define los manifiestos de workspace estrictamente. Usa extraPathGrants para rutas host a propósito. Fija los modelos de producción. Decide si los límites de turnos deben quedarse en el valor predeterminado, aumentarse o deshabilitarse con otras medidas de protección. Establece la concurrencia de herramientas local basada en efectos secundarios. Prefija los nombres de herramientas MCP cuando hay múltiples servidores conectados. Prueba los cambios de modelo realtime como cambios de comportamiento del producto, no solo como actualizaciones de dependencias.

[NOVA]: Gemini CLI v0.42 Nightlies Refuerzan los Bordes del Runtime de Agentes: Evaluaciones de Seguridad de Shell, Carreras de Aprobación, Colas de Compresión, Bloqueos de OAuth y Parches de Auto Memory Las nightlies de Gemini CLI del 6 y 7 de mayo son útiles porque muestran el trabajo poco glamoroso del runtime requerido para agentes de línea de comandos. Los cambios no son un solo lanzamiento de modelo; son una lista de casos extremos alrededor de aprobación, seguridad de shell, compresión de contexto, fallas de streaming, OAuth, nominación de sandbox, Auto Memory y salida no interactiva. Esos son exactamente los lugares donde los agentes CLI se vuelven frágiles.

[ALLOY]: Empieza con las aprobaciones. Las correcciones del servidor A2A resuelven una condición de carrera en la aprobación de herramientas, mejoran el reporte de estado y resuelven una carrera en la espera de completado de herramientas. En un runtime de agente, la aprobación es una máquina de estados. Se propone una llamada de herramienta, se solicita aprobación, llega una decisión humana o de política, la herramienta se ejecuta o se deniega, y el runtime reporta completado. Si el sistema reporta estado antes de que el resultado de aprobación esté comprometido, o espera la señal de completado equivocada, la UI puede mostrar una herramienta como completada mientras aún está pendiente, o ejecutar después de que un camino de denegación debería haberla detenido.

[NOVA]: Las evaluaciones de seguridad de comandos shell son una adición fuerte. Las herramientas de shell son poderosas porque permiten a los agentes inspeccionar archivos, ejecutar pruebas, instalar dependencias y operar flujos de trabajo de desarrolladores. Son peligrosas por la misma razón. Un conjunto de evaluaciones de seguridad de shell le da a los mantenedores una forma de probar si el modelo y el runtime identifican correctamente comandos riesgosos, redirecciones, operaciones destructivas de archivos, exposición de credenciales y intentos de escape del sandbox. La parte importante es que la seguridad se evalúa como comportamiento, no simplemente documentada como política.

[ALLOY]: Las nightlies también agregan salida JSON para AgentExecutionStopped en modo no interactivo. Eso importa para CI y scripts wrapper. Una TUI humana puede mostrar un estado detenido en prosa; la automatización necesita un objeto estructurado. Si las ejecuciones no interactivas se detienen por política, límite, error o estado de aprobación, la salida JSON permite a los sistemas llamadores distinguir una parada limpia de un crash o timeout. Los agentes CLI cada vez más se ejecutan dentro de trabajos programados y sistemas de orquestación, así que la semántica terminal estructurada es parte de la superficie del producto.

[NOVA]: La compresión de contexto obtiene una corrección de colas: los mensajes pueden ser encolados durante la compresión. La compresión es necesaria porque las sesiones de agente largas exceden los límites de contexto, pero también es un peligro de concurrencia. Si un usuario envía un mensaje mientras el runtime está comprimiendo el historial, el sistema tiene que decidir si bloquear la entrada, descartarla, agregarla al contexto viejo, o encolarla para el contexto comprimido. Encolar preserva la intención del usuario mientras permite al gestor de contexto terminar una reescritura coherente. Sin eso, la corrupción del chat o los turnos perdidos se vuelven probables.

[ALLOY]: El CLI también reintenta errores ERR_STREAM_PREMATURE_CLOSE. Las ejecuciones de agentes con streaming dependen de conexiones de larga duración a través de la salida del modelo, el progreso de herramientas y la renderización del terminal. Un cierre prematuro puede ser una falla transitoria de red o transporte en lugar de una falla lógica. Reintentando cuidadosamente se puede hacer el sistema más robusto, pero el runtime debe evitar duplicar efectos secundarios. El patrón seguro es reintentar rutas de streaming idempotentes o pre-ejecución y ser más conservador una vez que una herramienta ha mutado estado.

[NOVA]: Varias correcciones tienen que ver con entornos headless y no estándar. La CLI evita un bloqueo silencioso durante la autenticación OAuth en Linux headless. Rechaza IDs de proyecto numéricos en GOOGLE_CLOUD_PROJECT. Mejora la experiencia de MCP list en carpetas no confiables. Estas son correcciones de calidad para operadores. Muchos agentes se ejecutan en máquinas remotas, contenedores, workers de CI o servidores sin navegador. Los fallos de autenticación y resolución de proyectos necesitan fallar con un estado accionable, no quedarse colgados esperando una interfaz que no existe.

[ALLOY]: El comportamiento del sandbox recibe cambios pequeños pero importantes. La CLI randomiza los nombres de los contenedores sandbox y permite la redirección en modos YOLO y AUTO_EDIT sin sandbox. Los nombres de contenedores randomizados reducen colisiones cuando múltiples ejecuciones corren en el mismo host. El comportamiento de redirección importa porque la sintaxis de shell es parte del trabajo normal del desarrollador: redirigir salida a archivos, hacer piping de logs y escribir parches. Pero cualquier cambio alrededor de la redirección también necesita evaluación de seguridad porque la redirección puede sobrescribir archivos o exfiltrar contenido. Por eso las evaluaciones de seguridad de shell y los cambios de comportamiento de shell pertenecen a la misma discusión.

[NOVA]: Auto Memory obtiene un endurecimiento de la lista de permisos de parches privados y documentación más clara de que Auto Memory propone actualizaciones de memoria y skills. La memoria persistente solo es útil si las actualizaciones tienen alcance y son revisables. Una lista de permisos de parches de memoria controla qué tipos de actualizaciones de memoria privada pueden aplicarse automáticamente. Sin ese límite, un agente podría persistir hechos sensibles, incorrectos o excesivamente amplios. Con un límite demasiado estricto, la memoria se vuelve inútil. El modelo de operador correcto es: propuesta, alcance, lista de permisos y revisión.

[ALLOY]: El release del 7 de mayo también mueve la explicación de herramientas del stream de pensamiento al contenido de llamada de herramienta. Puede sonar como limpieza de interfaz, pero afecta la privacidad y observabilidad. Los streams de pensamiento y el contenido de llamadas de herramientas tienen diferentes audiencias y reglas de retención en muchos sistemas. Si una explicación de herramienta pertenece con la llamada de herramienta, ponerla ahí hace que los logs de auditoría sean más claros y evita mezclar la justificación de herramienta visible para el usuario con canales de razonamiento interno. Los runtimes de agentes necesitan estos límites de contenido para mantenerse consistentes.

[ALLOY]: Las correcciones de carrera de aprobación son especialmente importantes para servidores agente-a-agente. Cuando un agente le pide a otro runtime que haga trabajo, el lado solicitante solo puede ver un stream de estado. Si ese stream dice approved, denied, running y completed en el orden incorrecto, el código de orquestación puede hacer suposiciones inseguras. Un servidor A2A robusto trata aprobación, ejecución, cancelación y completación como estados separados con transiciones durables.

[NOVA]: Las evaluaciones de seguridad de shell también deben leerse como infraestructura de regresión, no solo como política. Una vez que un agente CLI soporta redirección, ediciones de archivo, gestores de paquetes y modos sandbox, los mantenedores necesitan ejemplos que prueben que el runtime detecta comandos destructivos, redirección de salida peligrosa, lecturas de credenciales y sintaxis de shell confusa. De lo contrario, la seguridad depende de revisión informal y se rompe cuando el modelo o el prompt cambian.

[ALLOY]: La corrección de la cola de compresión es otro punto de confiabilidad del mundo real. Las sesiones largas a menudo comprimen el historial exactamente cuando el usuario sigue activo. Encolar input durante la compresión preserva el orden de turnos: terminar el resumen, adjuntar el mensaje encolado al nuevo contexto y continuar. Descartar o crear carrera con ese input haría que la CLI se sintiera embrujada porque el siguiente mensaje del usuario se interpretaría contra la memoria incorrecta de la sesión.

[NOVA]: La recomendación práctica para operadores de Gemini CLI es ver estos nightlies como señales de endurecimiento de runtime. Las máquinas de estado de aprobación necesitan pruebas de carrera. Las herramientas de shell necesitan evaluaciones de seguridad. La compresión necesita encolado de input. El streaming necesita reglas de reintento que eviten efectos secundarios duplicados. OAuth necesita modos de fallo headless. Los parches de memoria necesitan listas de permisos. Las ejecuciones no interactivas necesitan estados JSON. Estos no son pulido opcional para un agente CLI; son la diferencia entre una terminal de demo y una superficie de automatización confiable.

[NOVA]: Hagamos la lista de verificación del operador concreta. Para despliegues de OpenClaw, el primer item de la lista después de este release es verificación de publicación. Si un plugin claims shipped de múltiples paquetes, el job de release debería comparar los nombres y versiones de paquetes planeados contra el resultado del registry. Eso protege a los instaladores, pero también protege al mantenedor, porque el incidente apunta al estado de distribución en vez de un vago reporte de usuario sobre una instalación fallida.

[ALLOY]: Segundo, trata el JSON de cron como la interfaz de monitoreo. Un dashboard no debería hacer scrape de la misma prosa que lee un humano. Debería leer estado, última ejecución, próxima ejecución, estado habilitado y estado de error directamente. Una vez que el estado es calculado por la CLI, los wrappers no necesitan reglas competiendo sobre si un job está idle, skipped, disabled o failed. Menos interpretaciones independientes significa menos alertas falsas.

[NOVA]: Tercero, separa la salud del enrutamiento de la salud del modelo. Una ruta de Discord, Telegram, WhatsApp o Slack puede estar configurada mientras falta una key de modelo, y un modelo puede estar autenticado mientras un canal está deshabilitado o con permisos incorrectos. La limpieza de listados de canales hace que esa distinción sea más fácil de preservar. También hace más fácil que los docs de soporte digan, revisa canales aquí, revisa auth de modelo ahí, luego revisa estado global para la imagen combinada del runtime.

[ALLOY]: Cuarto, para memoria y skills, asume que las sesiones de larga duración tienen vistas obsoletas a menos que el runtime pruebe que las invalida. Los snapshots de skills son útiles porque evitan reconstruir listas de capacidades cada turno. Los caches de contexto son útiles porque ensamblar contexto puede ser costoso. Pero ambos son peligrosos después de reset, reparación o reducción de historial. Las correcciones de invalidación de cache de este release son un recordatorio de que los resets deben limpiar no solo el historial de chat visible sino también artefactos de runtime derivados.

[NOVA]: Quinto, la entrega debe ser un preflight cuando sea posible y un resultado reportado después. Un cron job sin última ruta de entrega debería fallar antes de la ejecución del modelo. Un send path sin resultado de adapter no debería convertirse en un éxito fingido. Esto es especialmente importante para agentes programados, porque nadie está mirando la ventana de chat cuando ocurre el fallo. Los logs y campos de estado tienen que decir la verdad.

[ALLOY]: Para OpenAI Agents JS, la lista de verificación es diferente. Empieza pinchando modelos y modelos realtime en producción. Luego escribe manifests como si un reviewer de seguridad los va a leer, porque eventualmente alguien lo hará. Declara directorios locales intencionalmente. Usa grants de path extra sparingly y describe por qué existen. Decide cuáles outputs son artefactos, cuáles archivos son estado de workspace editable y cuáles archivos del host son inputs de solo lectura.

[NOVA]: Luego ajusta los límites de runtime. Un límite por defecto de diez turnos es un riel de seguridad; deshabilitarlo es una decisión de diseño. Si max turns es null, añade un timeout de reloj de pared, control de presupuesto y reportes de progreso. Si las herramientas de función local pueden correr concurrentemente, clasifícalas por efecto secundario. Las herramientas de búsqueda de solo lectura usualmente pueden paralelizarse. La instalación de paquetes, escrituras a base de datos, mutaciones de filesystem y comandos de shell merecen scheduling más estricto.

[ALLOY]: El naming de MCP es otro item de higiene de producción. Prefijar nombres de servidor en nombres de herramientas puede verse ruidoso, pero previene que el agente y los logs confundan la herramienta de búsqueda de un servidor con la de otro. En una demo pequeña, los nombres cortos se sienten más nice. En un ambiente de producción con docs internas, tickets, búsqueda de código, herramientas de browser y herramientas de datos de cliente, las colisiones de namespace se vuelven problemas de auditoría.

[NOVA]: Para Gemini CLI, la lista de verificación empieza con comportamiento no interactivo. Si un agente CLI va a correr en automatización, los estados stopped necesitan JSON. OAuth necesita fallar claramente cuando no hay navegador disponible. Los reintentos de streaming necesitan evitar efectos secundarios duplicados. La compresión necesita preservar el input de usuario encolado. Esos son requisitos aburridos hasta que el agente está corriendo dentro de CI, un shell remoto o un job programado.

[ALLOY]: La seguridad de shell merece su propia línea. La pregunta no es si las herramientas de shell son útiles; obviamente lo son. La pregunta es si el runtime puede distinguir inspección de mutación, redirección segura de sobrescritura destructiva, y comandos ordinarios de desarrollador de comandos de riesgo de credenciales o sandbox. Las evaluaciones de seguridad convierten eso en una superficie testeable. Permiten a los mantenedores atrapar regresiones cuando los prompts, modelos o comportamiento de parsing de shell cambian.

[NOVA]: La recomendación más amplia a través de las tres historias es diseñar para el momento después de la demo. Una vez que los agentes publican paquetes, corren cron jobs, se unen a canales de voz, editan archivos y llaman herramientas, el producto ya no es solo una interfaz de chat. Es un entorno operativo. Los entornos operativos necesitan contratos de estado, hooks de autorización, límites de filesystem explícitos, estados de aprobación durables, errores estructurados y paths de recuperación.

[ALLOY]: Y la mejor señal en estos releases es que esas superficies aburridas están recibiendo atención de producto. Verificación de publicación, resolución de SecretRef, invalidación de contexto, manifests de sandbox, grants de path extra, colas de compresión y evaluaciones de seguridad de shell no son capacidades de modelo destacadas. Son las partes que deciden si una plataforma de agentes puede ser confiable cuando nadie la está cuidando.

[NOVA]: Un detalle final de implementación: cada una de estas salvaguardas debe producir un artefacto que un humano pueda inspeccionar después. Un resultado de verificación de registro, un estado JSON de cron, una carga útil de decisión de aprobación, un manifiesto de sandbox y un objeto JSON de ejecución detenida son evidencia. Permiten a un mantenedor reconstruir lo que el agente creía, lo que el tiempo de ejecución permitía, qué herramientas se ejecutaron y a dónde se suponía que debía ir la salida.

[ALLOY]: Esa capa de evidencia es lo que convierte las operaciones de agentes de solo sensaciones en ingeniería. Si una automatización falla, no deberías tener que preguntar si el modelo alucinó, si faltaba la ruta, si la credencial no se resolvió, si el contexto estaba obsoleto, si el sandbox leyó demasiado, o si la interfaz de aprobación ofrecía la acción incorrecta. El sistema debería reducir esa búsqueda.

[ALLOY]: La conclusión práctica del EP047 es operativa: OpenClaw v2026.5.7 hace que el estado del sistema sea más visible y seguro en publicación, cron, canales, memoria, entrega, voz, mensajería y aprobaciones. OpenAI Agents JS muestra cómo los agentes en sandbox se están convirtiendo en runtimes de manifiesto de espacio de trabajo con permisos de ruta explícitos, límites de turnos, concurrencia de herramientas y namespaces MCP. Gemini CLI muestra los bordes del runtime que importan cuando los agentes de línea de comandos se ejecutan en flujos de trabajo reales: carreras de aprobación, seguridad de shell, colas de compresión, reintentos de transporte, vida útil de OAuth y alcance del parche de memoria. Para los constructores, la pregunta no es solo qué puede hacer el agente; es qué límites, estados y rutas de recuperación existen cuando hace el trabajo.

[NOVA]: Gracias por escuchar OpenClaw Daily. Las notas del programa y los enlaces de origen están en Toby On Fitness Tech punto com, y volveremos pronto.