Los agentes de programación están ganando autonomía, pero esa libertad introduce una pregunta incómoda: qué ocurre cuando un agente capaz de ejecutar comandos tiene acceso al mismo ordenador, archivos y credenciales que utiliza su propietario. ArcBox propone cambiar los avisos de permiso por aislamiento real: abctl claude ejecuta Claude Code dentro de una microVM independiente, con su propio kernel, sistema de archivos y red, sin montar por defecto los archivos del Mac anfitrión.
Las claves de ArcBox y Claude Code en 20 segundos
abctl claudeejecuta Claude Code dentro de una microVM desechable aislada del Mac.- Cada sandbox dispone de kernel y sistema de archivos propios y comienza con
/workspacevacío. - Los avisos de permisos de Claude Code se desactivan dentro de ese entorno porque la microVM actúa como frontera de aislamiento.
- ArcBox también ofrece compatibilidad con Docker, Kubernetes y máquinas virtuales Linux y macOS.
- El proyecto está escrito en Rust, se encuentra en beta pública y supera actualmente las 3.000 estrellas en GitHub.
El planteamiento resulta especialmente interesante porque aborda uno de los problemas que aparecen cuando herramientas como Claude Code pasan de sugerir unas líneas de código a ejecutar comandos, instalar dependencias, modificar archivos y trabajar durante periodos prolongados con poca intervención humana.
Aceptar manualmente cada operación puede ofrecer control, pero también puede generar fatiga. Cuando el usuario termina pulsando «permitir» casi automáticamente, el cuadro de diálogo pierde buena parte de su utilidad como mecanismo de seguridad.
ArcBox intenta trasladar esa responsabilidad a una capa inferior: en vez de confiar principalmente en que una persona examine cada acción, limita aquello a lo que el agente puede acceder.
abctl claude: Claude Code recibe una máquina desechable
ArcBox es un runtime abierto para macOS escrito desde cero en Rust. Sus responsables lo presentan como una alternativa de código abierto a Docker Desktop y OrbStack, aunque sus funciones van más allá de ejecutar contenedores.
El mismo daemon admite actualmente cuatro tipos principales de cargas: contenedores compatibles con Docker, sandboxes para agentes y código no confiable, máquinas Linux completas y máquinas virtuales macOS desechables.
La parte dedicada a agentes es probablemente la más llamativa.
Al ejecutar:
abctl claude
ArcBox prepara un sandbox y conecta el terminal con Claude Code dentro de él. Según la documentación del proyecto, estos sandboxes son microVM independientes que se ejecutan mediante Firecracker anidado dentro de la máquina virtual invitada.
No es simplemente un directorio separado.
Cada microVM tiene su propio kernel y sistema de archivos. Además, ArcBox asegura que no monta nada del ordenador anfitrión dentro del sandbox. /workspace comienza vacío y es el propio agente quien debe clonar aquello que necesite. Los resultados que interese conservar pueden copiarse posteriormente fuera de la máquina.
Ese detalle cambia el modelo de riesgo.
Un agente que ejecuta accidentalmente un comando destructivo puede destrozar su entorno de trabajo, pero la intención es que ese entorno sea precisamente una máquina desechable y no el sistema de archivos personal del desarrollador.
La documentación indica por ello que Claude Code se ejecuta con sus solicitudes de permiso desactivadas: ArcBox pretende que la frontera de seguridad sea la microVM y no cada confirmación individual del usuario.
De preguntar «¿permitir?» a limitar lo que el agente puede tocar
Los permisos siguen teniendo utilidad, pero el crecimiento de los agentes autónomos está haciendo más visible una limitación clásica de las interfaces de seguridad: demasiadas confirmaciones pueden acabar convirtiéndose en rutina.
El usuario lee las primeras. Después empieza a reconocer comandos habituales. Finalmente puede aprobar operaciones por inercia para que el agente continúe trabajando.
La aproximación de ArcBox se parece más a la utilizada desde hace años con cargas no confiables en infraestructura cloud: asumir que el proceso puede hacer algo inesperado y controlar su alcance mediante aislamiento.
Esto no convierte automáticamente cualquier operación realizada dentro de una VM en segura. Un agente continúa pudiendo acceder a aquello que deliberadamente se le proporcione, conectarse a servicios externos si la red lo permite o utilizar credenciales introducidas en su entorno. Una máquina virtual tampoco soluciona vulnerabilidades del hipervisor ni otros posibles escapes.
Pero sí reduce una clase importante de riesgo: que un agente con permisos amplios pueda recorrer directamente el sistema de archivos del ordenador personal simplemente porque se le autorizó a ejecutar un comando.
La filosofía resulta especialmente adecuada para tareas desechables: revisar un repositorio, ejecutar tests, compilar software desconocido, analizar código de terceros o permitir que un agente pruebe diferentes soluciones sin necesidad de conservar todo el entorno.
Firecracker llega al escritorio para aislar agentes de IA
La elección de Firecracker tampoco es casual. La tecnología de virtualización basada en microVM fue desarrollada originalmente por Amazon Web Services para ejecutar cargas como AWS Lambda y AWS Fargate buscando combinar tiempos de arranque reducidos con aislamiento mediante virtualización.
ArcBox aplica ese concepto a un escenario diferente: agentes locales.
Según su documentación, los sandboxes pueden crearse desde plantillas, imágenes Docker o Dockerfiles. También pueden guardarse snapshots de una máquina preparada y restaurarlos posteriormente para reducir el tiempo necesario para comenzar otra sesión.
Hay, sin embargo, requisitos importantes. Los sandboxes necesitan virtualización anidada y actualmente requieren Apple Silicon M3 o posterior y macOS 15 o superior, utilizando el backend VZ predeterminado. Por tanto, abctl claude no está disponible de la misma manera para cualquier Mac.
El proyecto se encuentra además en beta pública, algo que conviene tener presente antes de plantearlo como sustituto directo de herramientas maduras en entornos de producción.
También quiere competir con Docker Desktop y OrbStack
ArcBox sería bastante más limitado si únicamente envolviera Claude Code en una VM. Su objetivo es construir un runtime común para diferentes tipos de cargas locales.
Puede funcionar como motor compatible con Docker, exponiendo un socket que permite seguir utilizando Docker CLI, Compose, BuildKit y Buildx. También puede levantar un clúster local k3s y conectarlo con kubectl.
En Apple Silicon puede ejecutar imágenes linux/arm64 y linux/amd64; para estas últimas utiliza FEX para traducir x86-64 dentro del guest.
Cuando un contenedor resulta insuficiente, abctl machine crea máquinas Linux completas con kernel, disco persistente y distribución propia. Actualmente el proyecto documenta soporte para Ubuntu y Alpine.
ArcBox incluso puede crear máquinas virtuales macOS desechables, utilizando Virtualization.framework y clones copy-on-write de una imagen base. Apple limita este último escenario a dos invitados por host bajo las condiciones indicadas por el proyecto.
Todo ello se administra mediante un daemon y una CLI comunes.
La ambición explica por qué ArcBox se define como alternativa abierta a Docker Desktop y OrbStack más que simplemente como un sandbox para Claude Code. El repositorio se distribuye bajo doble licencia MIT o Apache-2.0 y, a 04/09/2026, GitHub muestra alrededor de 3.100 estrellas, por encima de las aproximadamente 2.900 que acumulaba cuando comenzó a circular ampliamente el proyecto.
Los agentes están convirtiendo el sandbox en parte de la infraestructura
ArcBox también refleja un cambio más amplio alrededor de los agentes de programación.
Mientras un asistente se limita a generar texto, el riesgo principal está relacionado con la calidad de su respuesta. Cuando ese mismo sistema obtiene herramientas para utilizar el terminal, modificar repositorios, descargar software y ejecutar programas, la seguridad del runtime pasa a formar parte de la arquitectura del agente.
La cuestión deja entonces de ser únicamente qué puede hacer el modelo y pasa a incluir dónde puede hacerlo.
Contenedores, microVM, credenciales temporales, redes restringidas, sistemas de archivos desechables y políticas de acceso pueden adquirir tanta importancia como el propio modelo utilizado.
ArcBox lleva esa idea hasta el escritorio del desarrollador: en vez de preguntar continuamente si Claude puede ejecutar la siguiente acción, le proporciona una máquina en la que puede trabajar con mucha más libertad y que posteriormente puede descartarse.
No elimina la necesidad de controlar qué secretos, repositorios o conexiones se entregan al agente. Tampoco convierte la ejecución autónoma en una actividad sin riesgo. Pero plantea una dirección interesante para la siguiente generación de herramientas de programación con IA: menos confianza depositada en el clic humano y más límites impuestos por la propia infraestructura.
Preguntas frecuentes
¿Qué es ArcBox?
ArcBox es un runtime abierto para macOS escrito en Rust que permite ejecutar contenedores, Kubernetes, sandboxes para agentes y máquinas virtuales Linux y macOS desde un mismo daemon y CLI.
¿Cómo aísla ArcBox a Claude Code?
abctl claude ejecuta Claude Code dentro de una microVM desechable basada en Firecracker. El sandbox dispone de kernel y sistema de archivos propios y, según el proyecto, no monta por defecto archivos del host.
¿ArcBox sustituye a Docker Desktop?
El proyecto se presenta como una alternativa abierta a Docker Desktop y OrbStack y ofrece un motor compatible con Docker. Está todavía en beta pública, por lo que su grado de madurez y compatibilidad debe valorarse según cada entorno.
¿Qué Mac necesita ArcBox para ejecutar sandboxes de agentes?
La función de sandbox y abctl claude requieren actualmente un Mac con Apple Silicon M3 o posterior y macOS 15 o superior debido al uso de virtualización anidada.
