CompozyOS 0.4.4 convierte las actualizaciones de escritorio en una prueba para las sesiones persistentes de agentes

Juzgar una actualización de escritorio es sencillo cuando la aplicación es un editor de notas: cierras la ventana, instalas la nueva versión y vuelves a abrir el archivo. El software para agentes tiene un contrato más exigente. Una sesión en ejecución puede estar transmitiendo resultados, mantener un árbol de trabajo, esperar una aprobación, registrando llamadas a herramientas o coordinando otra sesión cuando el entorno de escritorio necesita reiniciarse.

Por eso CompozyOS 0.4.4 resulta más interesante de lo que su breve registro de cambios podría sugerir. El registro oficial de cambios enumera una novedad principal para el 28 de octubre de 2026: conservar las sesiones activas durante las actualizaciones de escritorio. El proyecto es un entorno local-first para sesiones persistentes de agentes, bucles, automatización, permisos y múltiples superficies de control. En ese contexto, el comportamiento durante una actualización no es un detalle estético. Forma parte del modelo de fiabilidad del entorno de ejecución.

El consejo práctico es sencillo: prueba la versión 0.4.4 en un directorio de inicio de CompozyOS desechable o con copia de seguridad y, después, inicia deliberadamente una actualización mientras haya una sesión activa. No tomes una ventana conservada como prueba de que el trabajo también se conservó. Comprueba por separado el demonio, la transcripción, el estado del turno, la entrada en cola, los archivos adjuntos, el árbol de trabajo y la conexión con el proveedor.

Qué cambió en la versión 0.4.4

La página de la versión ofrece actualmente una descripción breve en lugar de un ensayo extenso sobre la funcionalidad: las sesiones activas deberían sobrevivir a una actualización de escritorio. El historial de versiones cercano explica por qué este límite es relevante. CompozyOS 0.4.0 fue la primera versión estable; la 0.4.1 corrigió varios casos relacionados con el escritorio y la recuperación del entorno de ejecución; la 0.4.2 abordó las lecturas de uso de Claude en segundo plano que podían solicitar acceso al llavero; y la 0.4.4 apunta ahora a mantener la continuidad durante la propia actualización de escritorio.

La secuencia importa porque CompozyOS tiene dos piezas estrechamente relacionadas: una aplicación de escritorio y un demonio local. La documentación del escritorio indica que tanto la aplicación de escritorio como el comando compozy utilizan el mismo demonio local, la misma configuración, los mismos espacios de trabajo y el mismo historial de sesiones. La aplicación puede conectarse a un demonio que ya funcione correctamente, iniciar el entorno instalado en el directorio de inicio de CompozyOS o instalar e iniciar el entorno incluido cuando sea necesario. Se supone que cerrar la aplicación no detiene el demonio.

Por tanto, una actualización de escritorio puede significar al menos dos cosas:

• reemplazar la interfaz gráfica mientras el demonio y su estado siguen disponibles;
• reemplazar un paquete que contiene tanto la aplicación como el entorno de ejecución y reiniciar la nueva pareja sin perder el estado persistente.

La palabra importante es «activa». Restaurar una lista de sesiones antiguas después del lanzamiento ofrece una garantía mucho más débil que mantener coherente un turno en curso. Una implementación útil debe conservar suficiente información sobre la propiedad y los eventos para que una sesión pueda continuar, reconectarse o informar de una interrupción clara. El titular de la versión, por sí solo, no nos dice cómo se comportarán todos los proveedores, sistemas operativos, rutas de instalación o modos de fallo. Eso es lo que deben probar los usuarios.

Por qué la continuidad del escritorio es un problema del entorno de ejecución

Muchas herramientas para agentes comienzan como un proceso de terminal. El proceso controla el aviso, la entrada estándar, el flujo de salida y, a menudo, el proceso hijo que ejecuta el cliente del modelo. Cerrar la terminal puede terminarlo todo. Un entorno de ejecución persistente cambia esa disposición: el demonio se encarga del trabajo, mientras la terminal, el navegador, la interfaz de escritorio u otro cliente lo observa y controla.

Ese diseño crea una separación útil. La interfaz puede desaparecer sin cancelar necesariamente el trabajo. También genera una ruta de actualización más exigente. Reiniciar un cliente solo es seguro si el demonio sabe qué ocurrió antes del reinicio y puede reproducir o reconstruir el estado después.

Una actualización de sesión puede atravesar varios límites:

1. El proceso de escritorio puede cerrarse o ceder el control a un instalador nativo.
2. El entorno de ejecución incluido en el paquete puede reemplazarse o reiniciarse.
3. El demonio puede seguir funcionando, recibir la orden de detenerse o ser detectado después del lanzamiento.
4. El proceso del proveedor puede continuar, reconectarse, fallar o rechazar el entorno restaurado.
5. La interfaz debe decidir si muestra resultados en directo, una transcripción de recuperación, una advertencia o un turno realmente detenido.

La documentación de CompozyOS describe el modelo general como un conjunto de sesiones propiedad del daemon, cuyos eventos se pueden inspeccionar mientras el trabajo continúa en segundo plano. Esa es la abstracción adecuada para una actualización, pero no debe confundirse con guardar un punto de control para cada efecto externo. Una transcripción puede ser persistente mientras un comando de shell sigue ejecutándose. Un worktree puede continuar asociado aunque un proveedor haya perdido la conexión. Un mensaje en cola puede estar almacenado sin que el agente lo haya recibido todavía.

Por eso, decir que «la sesión sobrevivió» debería significar algo más que «la fila sigue visible». Debería significar que el runtime puede indicar qué parte sobrevivió y cuál requiere intervención humana.

La primera prueba: actualizar durante una sesión inactiva

Empieza por el caso menos destructivo. Crea un espacio de trabajo de prueba, inicia una sesión, envía una instrucción que produzca una respuesta persistente y deja la sesión inactiva. Anota el identificador de la sesión, el espacio de trabajo, el perfil seleccionado y la ubicación del directorio de inicio de CompozyOS. Después, realiza la actualización de escritorio mediante el procedimiento documentado.

La guía de escritorio ofrece tres comandos útiles:

compozy update --check -o json
compozy update -o json
compozy update --cancel -o json

La documentación indica que la acción de la barra de menús o de Ajustes puede descargar, instalar y reiniciar la aplicación. También señala que la aplicación permanece abierta mientras su instalador nativo prepara el paquete verificado, mientras que una aplicación cerrada puede dejar la actualización preparada para el siguiente lanzamiento. En Linux, la instalación automática por canal de aplicación está limitada a la ruta de AppImage.

Después de la actualización, comprueba todo lo siguiente en lugar de confiar en la primera pantalla:

• la aplicación muestra la versión esperada;
• se está usando el mismo directorio de inicio de CompozyOS;
• los identificadores del espacio de trabajo y de la sesión no han cambiado;
• la transcripción anterior está completa y mantiene el orden correcto;
• el agente y el perfil seleccionados siguen asociados a la sesión;
• no ha aparecido ningún turno duplicado durante la reconexión;
• el daemon está saludable y la aplicación está conectada a él;
• la sesión puede aceptar una nueva instrucción.

Esta prueba responde si el estado persistido ordinario sobrevive. Todavía no responde si el producto puede gestionar una actualización mientras el trabajo está en curso.

La segunda prueba: actualizar mientras se ejecuta un turno

La prueba más útil emplea una instrucción que permanezca activa el tiempo suficiente para poder observarla. Es preferible usar un comando local de larga duración, una batería de pruebas acotada o una tarea controlada que produzca varios eventos de herramientas, en vez de una espera artificial. Utiliza un repositorio creado para la prueba y elimina de su entorno las credenciales sensibles.

Inicia el turno, espera a ver un evento claro de herramienta o progreso y comienza la actualización desde el entorno de escritorio. No envíes instrucciones adicionales hasta entender el resultado. Hay varios desenlaces aceptables, según la implementación:

• el daemon y el proveedor continúan, y el escritorio se reconecta al mismo turno activo;
• el turno termina mientras el escritorio se reinicia y después aparece con una transcripción completa;
• el runtime pausa o cancela el turno, registra el hecho con precisión y permite recuperarlo;
• el instalador se niega a continuar hasta que el trabajo activo se gestione explícitamente.

El desenlace peligroso es una sesión de aspecto normal que pierde en silencio el resultado de una herramienta, repite un efecto secundario o muestra una respuesta final sin el historial de eventos que la produjo. Un runtime de agentes persistente necesita pruebas más sólidas que un reinicio correcto de la ventana.

Usa una tarea cuyo efecto secundario pueda comprobarse dos veces. Por ejemplo, pide al agente de prueba que escriba un archivo con un nombre único y un nonce, y que después informe de su contenido. Tras la actualización, compara el archivo, la transcripción, el resultado de la herramienta y la respuesta final. Si la acción se ejecutó dos veces, la prueba debe hacerlo visible. No uses nunca un despliegue de producción, una migración destructiva, una acción de pago ni una rotación de credenciales reales para este experimento.

La tercera prueba: entradas y archivos adjuntos en cola

Una sesión activa no consiste únicamente en un turno del modelo. Los operadores pueden escribir una respuesta mientras el agente está ocupado, poner un mensaje en cola, orientar un turno o adjuntar archivos. Esas entradas son las que pueden revelar un estado dividido durante una reconexión.

Crea un archivo adjunto pequeño para la prueba y envía una instrucción que mantenga ocupada la sesión. Prepara una respuesta posterior, pero no pulses enviar hasta tener claro el comportamiento previsto de la cola. Durante la actualización, observa si el borrador sigue siendo un borrador, si el mensaje en cola continúa en cola y si una acción de orientación se entrega una sola vez en lugar de dos.

El historial público de lanzamientos del proyecto ha mencionado repetidamente la continuidad de las transcripciones, las entradas en cola, la mensajería de sesiones, los archivos adjuntos y la recuperación tras desconexiones del proveedor. Esas referencias muestran que los mantenedores consideran el estado de la sesión algo más que un registro de chat. También explican por qué conviene probar una versión actual en lugar de deducir todo el comportamiento a partir de un único titular.

Una lista de comprobación útil es:

• el texto no enviado sigue sin enviarse;
• la entrada en cola tiene un único estado de entrega;
• un archivo adjunto conserva una única identidad registrada y sigue siendo legible;
• un mensaje de dirección no se convierte en un duplicado de una solicitud ordinaria;
• un error del proveedor resulta visible, en vez de quedar sustituido por un indicador genérico de reconexión;
• se mantienen intactos el perfil de la sesión y los límites del espacio de trabajo.

Si la actualización cambia la posición de la sesión en la cola, regístralo como un comportamiento del producto. Puede ser aceptable, pero debe poder observarse y estar documentado.

Lo que 0.4.4 no demuestra

Una actualización de escritorio estable no equivale a un límite de ejecución seguro. El repositorio describe CompozyOS como un sistema local-first, con un binario de Go y almacenes respaldados por SQLite que mantienen el estado del entorno de ejecución en la máquina del operador, salvo cuando un proveedor externo o una extensión controla parte de ese límite. Esto facilita el control y la inspección, pero también significa que la máquina, la cuenta de usuario, las credenciales del proveedor, los archivos del espacio de trabajo y las extensiones instaladas siguen formando parte del modelo de confianza.

El repositorio está marcado como licenciado bajo MIT, y el README indica que se aceptan contribuciones. La apertura de la licencia responde a si se puede inspeccionar, modificar y redistribuir el código conforme a sus términos. No garantiza que todas las versiones sean maduras, que todas las integraciones ofrezcan las mismas propiedades de seguridad ni que una actualización no pueda revelar un problema de migración.

El material de migración del propio proyecto resulta especialmente pertinente. La guía de migración describe una corrección anterior en la que los metadatos de distribución etiquetaban por error los artefactos como BSL-1.1, aunque el proyecto seguía teniendo licencia MIT. También documenta los límites de compatibilidad entre líneas de producto antiguas y nuevas. Es un recordatorio de que conviene leer las notas de migración al cruzar límites importantes entre versiones, en vez de asumir que una actualización en el mismo lugar siempre se puede revertir.

La guía de operaciones de escritorio añade otra advertencia práctica: después de sustituir el binario del entorno de ejecución, un reinicio o una comprobación de salud fallidos pueden dejar instalada una versión de reemplazo que ya haya migrado las bases de datos. El consejo documentado es conservar la copia de seguridad para el diagnóstico, evitar restaurar un binario antiguo sobre un directorio de inicio posiblemente migrado y reinstalar la versión objetivo, o una versión posterior compatible, en el mismo directorio si fuera necesario. Ese tipo de detalle importa más que una animación de actualización pulida.

Quién debería probarlo ahora

CompozyOS 0.4.4 merece la prueba por parte de desarrolladores que ya necesiten que el trabajo de los agentes sobreviva a un terminal y que puedan proporcionar un directorio de inicio separado para las pruebas. También resulta relevante para quienes mantienen automatizaciones alrededor de sesiones de agentes locales, porque la ruta de actualización forma parte de la historia de disponibilidad de esa automatización. Si la aplicación se utiliza como interfaz de escritorio para un demonio de larga duración, la versión aborda directamente una interrupción que, de otro modo, los usuarios aprenden a temer.

Es una opción menos evidente para equipos que buscan un plano de control completamente gestionado, un aislamiento estricto entre los agentes y el anfitrión o un proceso maduro de gestión de cambios empresariales. El valor del proyecto está en su modelo de ejecución local: las sesiones, las tareas, los bucles, los permisos, las aprobaciones y la automatización comparten un modelo de estado propiedad del demonio. Esto puede eliminar una gran cantidad de código de conexión, pero también concentra la responsabilidad en la instalación local y su configuración.

Una prueba sensata tiene tres características:

• un espacio de trabajo desechable o una copia de seguridad verificada;
• ninguna credencial de producción en el entorno de prueba del proveedor;
• visibilidad suficiente para comparar la transcripción, el sistema de archivos, el estado de los procesos y los registros de actualización.

Conserva la versión anterior para compararla, pero no reviertas sin más un directorio de inicio que ya haya sido migrado. Haz una copia de seguridad completa antes de probar una ruta que modifique el entorno de ejecución o el estado de la base de datos.

Una breve comparación con otros enfoques

Si el requisito es simplemente «mantener un comando en ejecución después de cerrar la terminal», un multiplexor de terminal, un servicio del sistema o una cola de trabajos convencional pueden ser más fáciles de entender. Esas herramientas no ofrecen el modelo de sesiones orientado a agentes de CompozyOS, pero su comportamiento operativo resulta conocido y, a menudo, lo bastante acotado como para auditarlo.

Si el requisito es una interfaz de navegador para desarrollo remoto, una plataforma de desarrollo alojada o autogestionada puede ofrecer integraciones más sólidas de identidad, espacios de trabajo y auditoría. También puede imponer una dependencia de la nube y un límite de confianza distinto. CompozyOS apuesta, en cambio, por un demonio local con superficies de puerta de enlace explícitas; el intercambio consiste en controlar la máquina y asumir el trabajo operativo de mantenerla.

Si el requisito es un ejecutor de agentes independiente del modelo, una biblioteca de orquestación puede exponer primitivas de más bajo nivel y dejar la persistencia, las aprobaciones y la política de actualizaciones en manos de la aplicación. Esa puede ser la opción adecuada cuando un equipo ya cuenta con una capa de plataforma fiable. CompozyOS apunta al problema contrario: la capa de plataforma es precisamente lo que el equipo no quiere reconstruir para cada CLI de agente.

Por tanto, la comparación debería centrarse en la gestión de fallos, no en el número de funciones. Hay que preguntar cómo se comporta cada opción cuando la interfaz se reinicia, el proveedor se desconecta, el host se reinicia, hay un mensaje en cola, se ha ejecutado una migración de base de datos o un proceso hijo termina a mitad de una llamada a una herramienta.

El veredicto útil

CompozyOS 0.4.4 es una versión pequeña con una prueba implícita de gran alcance. Conservar las sesiones activas durante una actualización del escritorio es exactamente el tipo de función de fiabilidad que los usuarios solo perciben cuando falla. La función es valiosa porque CompozyOS se presenta como un entorno de ejecución local duradero, no como una simple ventana alrededor de una petición puntual.

La versión está lista para probar, pero no es motivo para confiar trabajo de producción sin supervisión a un sistema de agentes recién actualizado. Empieza con un entorno aislado. Prueba sesiones inactivas, turnos en curso, entradas en cola, archivos adjuntos, worktrees, reconexiones con el proveedor y la recuperación tras una actualización interrumpida. Conserva la transcripción y las pruebas del sistema de archivos, y comprueba qué hizo realmente el demonio.

Si esas pruebas salen bien, la versión 0.4.4 hace que la interfaz de escritorio deje de ser un único punto de interrupción. Si no, el fallo seguirá siendo útil: mostrará si la pieza que falta es la coordinación del instalador, la gestión del demonio, la recuperación del proveedor, la migración de la base de datos o simplemente un estado engañoso de la interfaz. Esa distinción es la verdadera medida de un entorno de ejecución de agentes de código abierto.