Dejé de construir cada Cell con Linux Containers y lo convertí en un usuario de macOS

✨ Resumen de GPT-5.6 Sol

Un registro de cómo abandoné el plan basado en una Linux VM y un Container por usuario para redefinir cada usuario de macOS con OpenClaw native como unidad de ejecución.

Le di la vuelta a la estructura básica en un solo día

Ayer conecté de verdad un coordinador con varios workers. Probé a separar entre Worktrees, Branches y commits los resultados creados por varias IA para integrarlos después.

Al mismo tiempo, estaba construyendo el entorno de ejecución de AI Orchestration. Hasta el día 14, la estructura básica era la siguiente.

Mac mini
→ 1 Colima Linux VM
→ un OpenClaw Cell Container por empleado

Crear una Image común y separar la Network y el Volume de cada empleado parecía práctico para desplegar y reproducir el entorno. Llegué a comprobar la Image Linux arm64 oficial de OpenClaw y a definir contratos para la child Image y la Cell Network. La idea de aislar el entorno de cada empleado en un Container ya estaba bastante avanzada.

Pero el día 15 retiré esa estructura como opción predeterminada.

Lo que quería construir no era un servicio de Containers

Cuando volví a escribir el objetivo de AI Orchestration, vi dónde estaba el desajuste.

Quería crear un entorno en el que los empleados solo tuvieran que expresar un objetivo en WebChat y su IA personal dividiera el trabajo necesario, eligiera herramientas y lo llevara hasta el final. No debía limitarse a producir código y documentos: también tenía que manejar aplicaciones de Mac, ejecutar Xcode y Simulator y dejar resultados reales con el Workspace y la Git identity del usuario.

En cuanto intentaba forzar el acceso a funciones de macOS desde un Linux Container, la estructura se volvía extraña. Había que colocar otro ejecutor fuera del Container, volver a unir permisos y estado, y transferir el Keychain y la GUI Session del usuario. La capa introducida para aislar obligaba a crear desvíos para acceder justo a las funciones necesarias.

OpenClaw tampoco era un simple stateless worker. Se parecía más al entorno personal completo de un usuario, con su Gateway, Profile, Session, Memory, OAuth y estado de ejecución. Quizá el error había empezado al definir un Cell como un solo Container.

El día 15 redefiní qué significaba Cell.

1 empleado
= 1 usuario de macOS
= 1 OpenClaw Gateway independiente
= 1 conjunto de UID, HOME y Keychain
= 1 conjunto de ChatGPT OAuth y CODEX_HOME
= 1 conjunto de Workspace, Git identity, Session y Memory

La nueva estructura creaba un usuario de macOS independiente por empleado en un mismo Mac mini y ejecutaba un OpenClaw Gateway completo de forma native dentro de cada usuario.

No borré Linux y Container como si hubieran sido un fracaso

Cambiar de dirección no significaba tratar como un fracaso todo lo que había hecho hasta el día 14.

El experimento con Containers había demostrado cosas concretas. Seguían siendo valiosas las pruebas sobre la Image oficial, la ejecución sin root, el root en modo read-only, la separación de Networks, los límites de Volumes y credentials, la procedencia de la Image y el restart.

Pero aquello no era la definición final de Cell.

La Linux VM y los Containers dejaron de ser el entorno Pilot predeterminado y pasaron a ser candidatos a sandbox solo para tareas concretas que realmente necesitaran ese aislamiento. macOS native sería la base, y Container una herramienta reservada para cuando su necesidad estuviera demostrada.

La diferencia era importante. Seguir adelante con la estructura de Containers solo por haber invertido mucho tiempo habría dejado que el entorno de ejecución arrastrara al producto. La cantidad implementada no justificaba la elección.

Separar usuarios de macOS tampoco completaba el aislamiento

La estructura native parecía más sencilla, pero había más cosas que verificar.

• ¿Coincidían el empleado que había iniciado sesión y el usuario real de macOS que ejecutaba el proceso?
• ¿Estaban asociados correctamente el Gateway, el OAuth, el Workspace y la autoría de Git de ese usuario?
• Si fallaba la autenticación de un usuario, ¿podía el sistema pasar a la de otro?
• ¿Era imposible acceder al HOME, Keychain, Port y Workspace de otros usuarios?
• Tras un cambio rápido de usuario o un reinicio, ¿recuperaba cada Gateway su propio estado?

Por eso no me limité a cambiar la topology en los documentos. Creé de nuevo el contrato y la Acceptance de los Cells native de macOS, y dejé como NOT_READY todo lo que no tuviera pruebas del Runtime real.

Que pasara un fixture de prueba tampoco demostraba que dos usuarios reales estuvieran aislados. Separé el hash de los archivos de entrada externos de las pruebas de ejecución del probe y seguí reforzando las comprobaciones para que no pudieran esquivarse mediante valores que fingieran pertenecer a otro usuario, symlinks o aliases de rutas de macOS basados en mayúsculas, minúsculas o Unicode.

Después de cambiar la topology a las doce del mediodía, pasé toda la tarde haciendo commits para cerrar cualquier agujero que permitiera «mentir diciendo que había pasado». Definir unas condiciones de aprobación honestas para la nueva estructura exigió más código que cambiar la propia estructura.

También separé el Workflow común del estado personal

Aunque cada empleado tuviera un entorno completamente independiente, el Workflow común administrado por la empresa debía desplegarse con la misma versión. A la inversa, actualizar ese Workflow no debía alterar el OAuth, la Memory ni el Workspace personales.

La tarde del día 15 fijé cada Workflow Release mediante version y content hash, y creé un contrato de admission que solo permitía seleccionar releases verificados. La selección de uno nuevo debía cambiar de forma atómica; las tareas en ejecución debían seguir fijadas al release que habían elegido al comenzar; y ni los rollbacks ni la limpieza podían eliminar un release todavía en uso.

Tampoco afirmé que estuviera desplegado en la ubicación de instalación compartida de un Mac real solo porque había creado el Source y las pruebas. Un Runtime sin instalar siguió siendo NOT_READY hasta el final.

El producto iba antes que el entorno de ejecución

El día 14 pensé cómo dividir varias IA e integrar sus resultados. El 15 volví a pensar qué era en realidad el Cell en el que iban a vivir.

No es que no doliera cambiar a macOS native después de haber preparado tanto la opción de Containers. Pero si el producto debía manejar aplicaciones de macOS, Xcode y el OAuth y la Memory de cada usuario, el entorno de ejecución tenía que seguir ese propósito.

Un Cell no era un único process aislado. Era el entorno completo de una IA personal en el que una persona trabaja con su propia autenticación, memoria, espacio de trabajo y herramientas.

El día 15 decidí dejar de apilar Containers sobre una Linux VM y usar al propio usuario de macOS como límite del Cell.