TL;DR:
- OpenClaw publicó el 30 de agosto de 2026 la versión v2026.8.1, que llama OpenClaw 2.0: 933 colaboradores, más de 16,000 pull requests y cerca de la mitad de todos los cambios fusionados en la historia del proyecto.
- La función estrella son las sesiones compartidas: otra persona puede entrar al trabajo que el agente ya tiene en curso o quedarse con él sin perder contexto.
- La documentación del proyecto pone el límite en la misma página donde anuncia la función: esos controles no son aislamiento entre inquilinos ni una frontera de seguridad.
OpenClaw publicó el 30 de agosto de 2026 la versión v2026.8.1, que el proyecto llama OpenClaw 2.0 y presenta como la mayor actualización de su historia: 933 colaboradores, 569 de ellos por primera vez, y más de 16,000 pull requests, cerca de la mitad de todos los fusionados desde que nació. El asistente de código abierto, que se instala en una máquina propia y conecta modelos de IA con aplicaciones de mensajería como WhatsApp, Telegram o Slack, rehízo la instalación y la aplicación de navegador, y estrenó las sesiones compartidas: otra persona puede entrar al trabajo que el agente ya tiene en marcha o quedarse con él sin perder el contexto. La documentación del proyecto marca el límite en la misma página donde anuncia la función: esos controles "no son aislamiento entre inquilinos ni una frontera de seguridad".
Quien puede escribirle al agente hereda su poder de herramientas
El manual de seguridad de OpenClaw arranca con una regla que ordena todo lo demás: una frontera de confianza por Gateway. El Gateway es el proceso que corre en la máquina y concentra sesiones, herramientas y canales de mensajería. Según ese documento, el escenario soportado es un solo operador o un equipo cuyos miembros ya confían entre sí; el que no está soportado es un Gateway y un agente compartidos por personas que no confían unas en otras.
El manual lo aterriza en una frase concreta: todo el que pueda escribirle a un agente con herramientas activadas comparte la autoridad delegada de ese agente. Si el asistente puede leer archivos, ejecutar comandos o mandar mensajes, quien lo alcance por chat puede intentar que los ejecute. Los roles de operador con nombre que trae la versión acotan qué puede hacer cada conexión, aunque el manual aclara que funcionan como barandales de colaboración y que la separación entre inquilinos es otra cosa. En la misma línea, aclara que el identificador de sesión sirve para enrutar la conversación y no funciona como credencial.
Para usuarios que sí puedan ser adversarios entre sí, la recomendación del proyecto no pasa por configurar mejor la función nueva: pide separar fronteras, con Gateways y credenciales distintos y, de preferencia, usuarios del sistema operativo o equipos separados. Quien quiera hospedar a varias organizaciones debe correr una celda aislada por cada una. El documento también incluye un comando de auditoría, openclaw security audit, que revisa quién puede activar al agente, qué tanto alcance tienen sus herramientas y si el Gateway quedó expuesto en la red.
Las notas de versión añaden un detalle operativo para quien reparta accesos: cuando alguien pierde un permiso, la interfaz puede seguir mostrándolo disponible durante un momento, hasta que la vista se actualiza o el Gateway rechaza la acción.
El propio manual ofrece una mitigación que depende menos de la configuración y más de qué modelo se elige. Cita un ejercicio de 2026 con 272,000 ataques repartidos en 41 escenarios de agentes, contabilizados solo cuando el agente ejecutaba la acción dañina y además se la ocultaba al usuario: las tasas de éxito fueron de 0.5% con Claude Opus 4.5, 1.0% con Sonnet 4.5, 1.3% con Haiku 4.5 y 8.5% con Gemini 2.5 Pro. El mismo texto pone dos frenos a esa lectura optimista. Un atacante humano que adapta su estrategia supera el 80% de éxito contra defensas de última generación, según cifras publicadas que el documento no detalla, y los modelos pequeños o antiguos siguen siendo mucho más fáciles de manipular. De ahí la instrucción del proyecto: para un agente con herramientas o con acceso a correo no confiable, no usar niveles de modelo débiles.
Block tomó otro camino con el mismo problema: en Buzz, el espacio abierto que presentó en julio de 2026, cada agente lleva su propio par de claves criptográficas y permisos definidos.
Alejandro Castillo Leone
Incógnito no te esconde del proveedor ni de quien opera el Gateway
La versión suma un modo Incógnito que viene desactivado por defecto y que las notas de versión describen con un alcance deliberadamente estrecho. La conversación vive en la memoria del proceso, no escribe en disco ni la transcripción normal ni la memoria automática del asistente, y desaparece cuando el Gateway se reinicia.
Lo que no hace está enumerado con la misma claridad. El proveedor del modelo sigue recibiendo los mensajes. Las herramientas pueden seguir escribiendo archivos o tocando servicios externos. Queda registro de auditoría sin contenido. Y quien opera el Gateway puede ver el trabajo en vivo.
Hay un matiz más para quien comparta computadora: la carga rápida del historial reciente se apoya en una copia acotada de la transcripción guardada sin cifrar en el perfil del navegador.
Los 575 milisegundos salen de una prueba contra un Gateway simulado
El dato de rendimiento que acompaña al rediseño de la interfaz web viene con condiciones muy acotadas. OpenClaw reporta que, en una prueba de chat por defecto contra un Gateway simulado con 50 milisegundos de latencia HTTP/1.1, el arranque bajó de cerca de 1.6 segundos a 575 milisegundos y las peticiones de JavaScript pasaron de 140 a 45. La medición es del propio proyecto y en condiciones de laboratorio.
Las cifras que acompañan al lanzamiento miden cosas distintas: dos describen rendimiento de laboratorio y dos, el tamaño del desarrollo.
| Cifra | Qué mide | Condición declarada |
|---|---|---|
| 575 ms | Arranque de la interfaz web en un chat por defecto | Prueba propia contra un Gateway simulado con 50 ms de latencia HTTP/1.1; antes, cerca de 1.6 s |
| 45 peticiones | Solicitudes de JavaScript en ese mismo arranque | Misma prueba simulada; antes, 140 |
| Más de 16,000 | Pull requests incluidos en la versión | Cerca del 50% de todos los fusionados en la historia del proyecto, según OpenClaw |
| 933 | Personas que aportaron código a esta versión | 569 de ellas contribuyeron por primera vez |
La página que sostiene todas esas cifras lleva encima un aviso del propio proyecto: la declara borrador, en revisión editorial activa, y advierte que el contenido, la agrupación, la redacción y las listas de fuentes todavía pueden cambiar.
Antes de actualizar, el cambio que complica volver atrás
La actualización mueve sesiones y transcripciones a SQLite, y ese cambio de almacenamiento tiene consecuencias en una sola dirección. Para regresar a una versión anterior basada en archivos hay que restaurar antes los artefactos de transcripción heredados con la CLI nueva, y las sesiones creadas después de la migración no aparecen en las versiones viejas. El proyecto pide una copia de seguridad verificada antes de actualizar.
El resto del rediseño apunta a bajar la barrera de entrada. La instalación guiada empieza buscando accesos de IA que ya estén en la computadora, desde una sesión iniciada de Codex, ChatGPT o Claude hasta una clave de API o modelos locales de Ollama y LM Studio, y comprueba que la opción elegida responda antes de guardarla. Las instalaciones en red que dejarían el Gateway expuesto sin autenticación quedan bloqueadas antes de tocar nada.
La versión también permite que el trabajo de una sesión corra en otro equipo emparejado o en una máquina rentada por horas. Ahí el manual sí marca una separación a favor del usuario: la inferencia sigue pasando por el Gateway y las credenciales del proveedor nunca llegan a la máquina remota.
Para el desarrollador o el equipo hispanohablante que ya tenía uno de estos asistentes corriendo en su laptop, la actualización cambia dos cosas a la vez. Vuelve mucho más fácil compartir el agente con alguien más y, a la vez, deja por escrito que ese "compartir" es una comodidad entre personas que ya confían entre sí y no un muro entre ellas. Repartir accesos dentro de un mismo Gateway es una decisión de organización; separar riesgos sigue exigiendo instalaciones distintas.
