Un entorno aislado para Claude Code: entornos de agente aislados en una computadora portátil

Cuando un reinicio borra tu memoria de trabajo

Imagina seis o siete sesiones de Claude Code abiertas al mismo tiempo. Algunas están en terminales, un par funcionan dentro de VS Code, otra se ejecuta en IntelliJ porque el equipo trabaja con varios lenguajes y cada uno tiene su editor favorito. Acceden a repositorios diferentes, realizan tareas distintas y manejan ideas a medio terminar. Luego el portátil se reinicia.

No hay nada malo con el código en sí. Lo que se pierde es la ubicación de todo: qué sesión estaba en medio de un refactorizado, cuál esperaba una compilación y cuál había planteado una pregunta cuya respuesta nunca se leyó. Se pasan veinte minutos reconstruyendo la memoria de trabajo a partir del historial de la shell y las ramas sucias de Git. En ese punto, un día malo comienza a parecerse a un problema de diseño.

El reinicio fue solo el síntoma más evidente. Había tres problemas separados que estaban desgastando todo poco a poco.

Mezcla de agentes. Lanzar agentes es económico, pero hacer un seguimiento de ellos resulta costoso. Cada uno nuevo requiere otra pestaña de terminal, otra ventana de editor y otro espacio en la memoria. La computadora portátil se convierte en un montón de ventanas, con el ser humano como única capa de integración. Las herramientas existentes suponen un agente, una tarea y una persona que supervisa, pero no es así como se lleva a cabo el trabajo.

El dilema de los permisos. Nada en la configuración por defecto resuelve este problema. Claude Code exige aprobación para las llamadas a herramientas, pero puede consultarte sobre algo menor mientras permanece en silencio respecto a una llamada que podría causar daños reales. El comportamiento ha mejorado, pero el problema fundamental sigue igual, ya que el agente actúa en tu nombre y posee tus privilegios. Un administrador de una organización de GitHub no puede aprobar razonablemente cada llamada a API, ni tampoco puede fingir que una sola aprobación es inofensiva.

Quedan dos opciones. Puedes seguir ajustando la lista de permisos hasta que se convierta en un artefacto privado que ningún colega pueda descifrar, o puedes activar --dangerously-skip-permissions y confiar en la suerte. Las historias de terror provienen de esa segunda opción, como el caso del agente que eliminó sin pensar una base de datos en producción. Ambos enfoques fracasan por la misma razón: el agente lleva tu identidad, y aprobar comandos uno por uno solo sirve como solución temporal a ese problema.

Cansancio por la instalación. Varios repositorios en diferentes entornos presentan un JDK faltante, el Node incorrecto, este SDK, aquel CLI, además de una versión establecida hace medio año que ya nadie puede explicar. Cada cambio de contexto implica un costo en forma de minutos dedicados a usar un gestor de paquetes. La situación empeora cuando se pierde o reemplaza una laptop, ya que cada entorno debe reconstruirse herramienta por herramienta. Después de meses ajustando el CLI de programación favorito, queda abierto el interrogante de si realmente se puede reproducir la configuración o si habrá que empezar de nuevo con la esperanza de recordar las partes importantes.

Máquina propia para el agente

No comenzó como un proyecto de plataforma. Capsule era una herramienta personal, creada para hacer que la semana de un ingeniero fuera menos molesta. La premisa era simple: darle al agente una máquina propia, no la tuya, donde no pudiera ver tu sistema de archivos ni usar tus credenciales, y donde decir “adelante, no preguntes” no fuera imprudente. También tenía que ser lo suficientemente económica como para permitir que varias funcionaran simultáneamente sin problemas.

Los compañeros de trabajo se dieron cuenta y pidieron la suya, y luego lo hicieron otros también. Superó su origen como herramienta de una sola persona y ahora se abre en las pantallas de un número cada vez mayor de ingenieros cada mañana, pasando de unos pocos usuarios iniciales a unas cuantas docenas, con gran parte del grupo de ingeniería probablemente siguiendo ese mismo camino. Nadie es forzado a usarlo. La gente lo adopta porque la semana se vuelve más fácil, que es la única señal de adopción fiable. Un nuevo empleado instala Capsule en una laptop y puede trabajar de forma completamente autónoma desde el primer día.

En una sola frase, Capsule le brinda a Claude Code un entorno aislado y listo para usar donde puede trabajar por su cuenta en tus repositorios, de modo que ya no funciona con todos tus privilegios completos.

La imagen muestra la Estación Cápsula. Las cápsulas se muestran a lo largo del borde izquierdo, la terminal del agente seleccionado ocupa el centro, y las solicitudes de pull request que usted posee o a las que se le ha pedido revisar se encuentran en la parte inferior izquierda, ofreciendo una sola ventana para toda la flota.

Su alcance es intencionalmente limitado. No se trata de un marco de orquestación de agentes ni de un producto multiagente, al menos por ahora, aunque podría aparecer alguna funcionalidad de orquestación en breve. Tampoco es un IDE, ni integra plugins o editores, y no crea una bifurcación ni reemplaza a Claude Code, ya que lo que funciona en su interior es simplemente Claude Code configurado de cierta manera. No sustituye a CI/CD, ni es un servicio SaaS alojado en la nube, ya que todo ocurre en su ordenador portátil.

Ese último punto resultó ser más importante de lo esperado. Al no haber costo por asiento y al no haber nada que ejecutar, una décima cápsula cuesta lo mismo que la primera, lo que convierte el trabajo en paralelo de un lujo en algo rutinario. La máquina ya está pagada, y los repositorios permanecen en el hardware desde donde comenzaron.

Dentro de una cápsula, Claude funciona con --dangerously-skip-permissions y nunca pregunta si puede ejecutar una orden. Sus únicas dudas se refieren a la intención, es decir, a qué hacer, y nunca a los permisos. Ese es un valor por defecto sensato solo gracias a dos factores subyacentes.

El entorno aislado

Cada cápsula funciona como un pod en el clúster de Kubernetes que OrbStack ya proporciona en la Mac. Eso mantiene todo local, sin infraestructura adicional ni facturas de nube. No se puede acceder al sistema de archivos del host, y dos volúmenes declarados almacenan datos persistentes: un espacio de trabajo y una caché de imágenes Docker. Tres capas restringen el tráfico saliente:

• Las reglas de kernel iptables bloquean los puertos salientes directos 80 y 443 para el ID de usuario del agente.
• Una NetworkPolicy de Kubernetes reduce lo que queda a DNS, 80 y 443.
• Lo que sobrevive pasa por un proxy Squid que aplica una lista de permisos explícita de dominios.

La lista de permisos incluye GitHub, npm, Maven, ECR y la API de Anthropic; por defecto, se deniega el acceso a cualquier otro destino. Un agente no tiene forma sencilla de llegar a un endpoint arbitrario y subir su código fuente, y lograrlo requeriría verdadera ingeniosidad.

Tres capas impiden que algo salga: las reglas del kernel, luego la política de red y finalmente el proxy de lista de permisos.

Credenciales con mínimo privilegio

Aquí radica el verdadero valor. La autenticación se realiza en el host bajo su propio nombre, con todos los roles que normalmente tiene. Esos roles permanecen en el keychain de macOS y nunca llegan a la cápsula. En su lugar, el host crea un token de alcance restringido y vida útil corta e inyecta ese token:

• una credencial temporal de AWS STS limitada a un rol de producción de solo lectura
• un token de GitHub, cuyos alcances se verifican antes de ser utilizado
• una cuenta de servicio de BigQuery de solo lectura que el agente suplanta, de modo que sus propias credenciales no se ven involucradas

Si se proporciona algo más amplio, como un rol de administración de producción SSO o un token con escopos excesivos, el host se niega rotundamente a insertarlo. La defensa es la opción por defecto, y desde el interior, el agente no tiene forma de volver a autenticarse ni de federarse para obtener un acceso más amplio. La identidad se mantiene, por lo que el registro de auditoría sigue atribuyendo la consulta a usted, pero lo que puede verse afectado se limita al rol y no se extiende a usted.

Usted inicia sesión como usted mismo en el host, y el agente solo recibe un token estrecho y de corta duración generado a partir de ese acceso. Este equilibrio permite que todo funcione correctamente. Permitir que un agente funcione sin supervisión no se basa en confiar más en él, sino en hacer que el peor escenario sea irrelevante.

Eliminar las barreras

La seguridad brinda la posibilidad de ser autónomo, pero no garantiza una experiencia positiva. La mayor parte del esfuerzo se ha dedicado a eliminar las barreras.

La imagen base desde la cual arrancan las cápsulas ya contiene versiones fijas de los conjuntos de herramientas: Go, Rust, Node, el JDK, Maven, sbt y Scala. Además, funciona un sidecar de Docker dentro de Docker que proporciona a cada cápsula su propio entorno Docker funcional, de modo que las pruebas de integración y los conjuntos Testcontainers se ejecutan sin afectar a las cápsulas vecinas. También están disponibles herramientas de línea de comandos con sesión iniciada, como la CLI de GitHub, la AWS CLI, gcloud y bq. De forma predeterminada existen servidores de lenguaje (Metals, jdtls, gopls, rust-analyzer, vtsls), lo que permite al agente navegar por el código mediante símbolos, usando funciones como ir a definición, buscar referencias y analizar jerarquías de llamadas en lugar de realizar búsquedas aleatorias.

Los cachés de las dependencias se comparten entre las cápsulas a través de un volumen del host. Parece un detalle menor, pero no lo es. En la primera versión, cada nuevo entorno descargaba todo de nuevo, y una herramienta que tarda veinte minutos en ejecutarse con Maven antes de cada tarea no sería adoptada. Ahora, una cápsula ya lista se crea en aproximadamente veinte a treinta segundos.

Lo que más cambió el comportamiento del agente fue un verdadero ciclo de retroalimentación. Una plataforma interna basada en CLI funciona dentro de la cápsula: se verifica el token SSO del host, se limita su alcance y se inyecta, lo que permite al agente crear un entorno de aislamiento, desplegar la rama que acaba de construir y ejecutar pruebas básicas allí. El conjunto de herramientas para pruebas de integración también se ejecuta en su interior, cargando imágenes reales y iniciando instancias reales de MySQL, Kafka y Cassandra en el sidecar. Al principio es lento mientras las imágenes pasan por el proxy, pero luego se vuelve rápido. Eso distingue a un agente que genera código plausible de uno capaz de indicar si el código funciona.

También está integrada la capacidad de búsqueda. Cada cápsula cuenta con una pasarela MCP interna que solo permite lectura y ofrece unas pocas decenas de herramientas. Puede acceder a registros de servicios y pods, métricas a través de PromQL y Thanos, paneles de control de Grafana, eventos de Kubernetes, el estado de las compilaciones CI, quién está de guardia y qué alertas se están activando, la asignación de responsabilidades por servicios, así como realizar búsquedas en Confluence y Slack. Dado que no se puede escribir en ella, activarla en todas partes no conllevaba ningún riesgo. Un mercado de plugins añade habilidades para compilaciones Maven, estructuración de servicios, gestión de entornos aislados y revisión de solicitudes de cambio, de modo que el agente ya conoce las convenciones internas desde el primer minuto.

Aquí hay un hábito que vale la pena adoptar. Mantenga un repositorio privado con comandos personales y plantillas de planificación, y Capsule lo clonará en cada entorno creado. De este modo, su propio flujo de trabajo lo seguirá a dondequiera que vaya. Los planes y los recuerdos también se transfieren entre cápsulas a través de ese repositorio, y una función de transferencia puede indicar dónde terminó una sesión y guardar un resumen, de modo que la siguiente cápsula comience con el contexto ya disponible y no desde cero. Se trata de un repositorio git ordinario, por lo que el agente también puede mantener sus propias herramientas, y basta con una instrucción como “agregar un comando de compilación y prueba, guardarlo y subirlo”.

Estacionar es mejor que empezar de nuevo

Surgió un efecto no planeado. Una vez que crear un agente aislado se vuelve sencillo y cada uno persiste independientemente de si alguien lo está supervisando o no, el trabajo deja de realizarse una tarea a la vez.

En una tarde típica, cuatro o cinco cápsulas están activas. Una trabaja sin intervención humana en la corrección de errores, otra es una sesión SSH para programación en pareja real, otra vuelve a ejecutar una prueba de integración problemática y abre una solicitud de pull cuando esta pasa, y otra se ocupa lentamente de actualizar dependencias que nadie quiere supervisar. Aproximadamente diez más permanecen detenidas: una idea a la que volver, un experimento que falló de manera interesante, un diseño considerado solo a medias. Detenerlas mantiene los repositorios, sesiones y cachés, y reanudarlas toma segundos, así que una línea de pensamiento no se abandona solo porque no sea la prioridad del día.

La parte costosa nunca fue comenzar el trabajo, sino dejarlo en suspenso. Y cuando algo se termina, se elimina la cápsula, sin complicaciones en el worktree de git ni tareas de limpieza, y todos los subproductos desaparecen junto con ella.

La autonomía total elimina las últimas fricciones. No hay solicitud de aprobación para una orden git, no es necesario buscar en una pestaña del navegador un número en una página de CI ni revisar un registro de compilación en busca de la única línea relevante. El agente se encarga de todo, y con la sandbox y los tokens limitados en su lugar, esto no equivale a simplemente arriesgarse al azar.

Cuatro cápsulas, cuatro estados; ninguno depende del ser humano.

Hay dos modos en un mismo motor. Puedes trabajar junto al agente en una sesión interactiva de tmux, o darle una instrucción y dejarlo actuar por sí mismo.

Esa es la razón por la que la interfaz funcionó bien. La CLI era potente, pero ejecutar repetidamente list, ssh y status en una terminal no es forma alguna de gestionar una flota. Capsule Station llena ese vacío con una sola ventana: las cápsulas en una barra lateral, un terminal integrado para cada una, además de las solicitudes de pull request y de revisión. Cambiar de agente es como cambiar de pestaña en un navegador. La aplicación utiliza Tauri, pesa unos diez megabytes y se basa en el webview del sistema, ya que mostrar una lista no debería requerir un Chromium empaquetado ni un gigabyte de espacio en disco. Tiende a permanecer abierta todo el día, mientras que el IDE rara vez lo hace.

También es justo mencionar qué deja sin tocar. La calidad del código generado no mejora. Lo que desaparece es el trabajo duro asociado a él: reorganizar, aprobar, instalar, volver a autenticarse y perder el lugar donde se estaba trabajando, lo cual resultó ser la mayor parte de las dificultades.

¿Por qué construir en lugar de comprar?

Las opciones basadas en servicios alojados son reales y cada vez mejores, como las cajas de pruebas en la nube ofrecidas por varios proveedores y los agentes que se ejecutan de forma remota para usted. No imponen carga operativa y permiten escalar realmente. Pero el código y las credenciales salen de su entorno, las cadenas de herramientas son genéricas, lo que ralentiza el inicio de ejecución en bases de código grandes, y no es posible implementar un modelo interno de identidades. También existen proyectos de código abierto, como cajas de pruebas nativas de Kubernetes, herramientas para contenedores de desarrollo y las primitivas locales de aislamiento que proporcionan los proveedores. Son neutrales con respecto a los proveedores y se basan en primitivas sólidas, aunque de bajo nivel, dejándolo a usted a cargo de la imagen, la autenticación y toda la experiencia del usuario. En cualquier caso, una preocupación legítima es si dicha opción seguirá recibiendo mantenimiento en seis meses, ya que todos lanzan iniciativas y pocas perduran.

El edificio se encontraba entre los dos. La cápsula está compuesta en gran medida por elementos predefinidos: DevPod se encarga del contenedor de desarrollo y del ciclo de vida de los pods, Squid gestiona la salida de datos, el clúster Kubernetes que ya proporciona OrbStack, además de una imagen de espacio de trabajo personalizada, autenticación mediada por el host y Station como capa superior. El vínculo con la solución es superficial y las partes pueden ser reemplazadas. Se adapta al conjunto de código y al modelo de autenticación, y el código permanece en la computadora portátil, aparte de lo que el agente envía a la API del modelo, al igual que ocurre con todas las opciones aquí presentes.

Las credenciales se generan en el host, mientras que todo lo que toca el agente se ejecuta dentro de un pod detrás de un proxy con una lista de permisos.

También existe el argumento de la flexibilidad, que resultó ser más importante de lo esperado. Si alguien desea una función específica, abre una solicitud de integración y se discute su implementación, para luego ser incluida en la versión final. Nadie pasa tres semanas explicándole a un gerente de producto que esa función podría formar parte del plan para el próximo año.

El riesgo es real y merece ser mencionado: el equipo se hace responsable de él, y en esencia se trata de un proyecto de una sola persona con el apoyo de la empresa. El desarrollo nunca ha sido tan económico, y el costo de mantenimiento es lo realmente incierto. Nadie tiene esa respuesta aún.

Qué viene a continuación

Se avecina una implementación más amplia, desde docenas de usuarios hasta toda la organización, además de más habilidades y herramientas integradas en la imagen, así como más conexiones de integración. Este último punto es más difícil de lo que parece, ya que cada una requiere una respuesta sobre qué puede hacer un agente en modo automático sin preguntas. El acceso de solo lectura es sencillo, pero cualquier operación de escritura exige una discusión seria y una forma de marcar las acciones destructivas. La operación remota es, con diferencia, la función más solicitada; por eso las cápsulas seguirían funcionando incluso con el portátil cerrado.

Advertencia sobre las brechas de seguridad

El sistema es deliberadamente defensivo, y su desarrollo implica una lección incómoda: una herramienta que otorga autonomía a los agentes depende en gran medida de las debilidades de un modelo de seguridad. Un buen control de acceso facilita la integración, mientras que su ausencia causa problemas de inmediato y muestra exactamente por qué.

Aun así, un entorno aislado tiene sus limitaciones. Ejecutar un agente con privilegios totales es como llevar armas cargadas, ya sea que se disparen o no. Capsule elimina esos problemas. Sin embargo, si pegas un token de administrador en el chat y le dices al agente que lo use, se le devuelven esos privilegios.

Ve a desarrollar

Estos son tiempos extraordinarios, y es difícil exagerar lo que un ingeniero puede crear. Todo comenzó como la molestia de una sola persona en una tarde cualquiera y se convirtió en algo que cada vez más compañeros de trabajo abren cada mañana. Quedan dos condiciones: debes saber qué problema deseas resolver y necesitas apoyo, ya que los tokens cuestan dinero y alguien tiene que estar de acuerdo en que valen la pena. Con ambos elementos, el trabajo ha cambiado permanentemente, así que busca los problemas y solúyelos.