- Cómo usar de forma segura la bandera
--dangerously-skip-permissions de Claude Code
- Tras evaluar varios entornos de ejecución aislada como Docker, VM y Firejail, se concluyó que una máquina virtual (VM) basada en Vagrant era la opción más adecuada
- Con Vagrant se mantiene el aislamiento completo de la VM, una configuración reproducible y el uso compartido de carpetas locales, evitando al mismo tiempo los problemas de Docker-in-Docker
- Se configuró Claude Code para que pudiera manipular libremente el sistema con privilegios
sudo dentro de la VM, y en la práctica ejecutó una web app, configuró la BD y automatizó pruebas, entre otras tareas
- Este enfoque es eficaz para prevenir daños al sistema de archivos por errores accidentales y, si hace falta, permite reinicializar de forma segura eliminando y recreando la VM
Antecedentes
- Al usar Claude Code, se intentó utilizar la bandera
--dangerously-skip-permissions para evitar la molestia de tener que confirmar solicitudes de permisos a cada momento
- Esta bandera realiza automáticamente todas las tareas sin aprobación previa, como instalar paquetes, cambiar configuraciones o borrar archivos
- Es eficiente porque no interrumpe el flujo de trabajo, pero existe el riesgo de dañar el sistema de archivos
- Para evitarlo, se identificó la necesidad de ejecutarlo en un entorno separado de la cuenta del sistema operativo host
Métodos considerados
- Primero se evaluó el aislamiento mediante Docker, pero como Claude necesita construir imágenes y ejecutar contenedores, se requiere una configuración de Docker-in-Docker
- En ese caso se necesita el modo
--privileged, por lo que el objetivo del sandbox pierde sentido
- Además, aumentan la complejidad y la inestabilidad por temas como anidación de red y problemas de permisos al montar volúmenes
- Como otras alternativas, se revisó lo siguiente
- Ejecución en bare metal: en casos de Reddit hubo daños graves, como eliminación de bases de datos o del directorio home
sandbox-runtime: control de acceso basado en ACL; Claude no puede acceder fuera del código, pero no ofrece libertad total- Firejail: tiene restricciones similares a Docker
- Configuración manual de VM: falta de reproducibilidad
- VM en la nube: problemas de costo, latencia y necesidad de subir el código
Enfoque basado en Vagrant
- Con Vagrant se logró un aislamiento completo de la VM y una configuración reproducible
- Gracias a las carpetas compartidas, se puede acceder como si fuera local
- No hay problemas de Docker-in-Docker y, si es necesario, la VM puede eliminarse y recrearse fácilmente
- Al usar VirtualBox 7.2.4 se detectó un bug de uso de CPU al 100%, y se confirmó la causa mediante un issue en GitHub
- La configuración final del Vagrantfile tiene las siguientes características
- Usa la imagen base
bento/ubuntu-24.04
- Asigna 4 GB de memoria y 2 CPU
- Instala Docker, Node.js, npm, git y unzip
- Instala globalmente
@anthropic-ai/claude-code
- Agrega el usuario
vagrant al grupo de Docker
Forma de uso real
- En el directorio del proyecto se ejecuta
vagrant up → vagrant ssh → claude --dangerously-skip-permissions
- En el primer arranque, el aprovisionamiento tarda unos minutos y solo hace falta iniciar sesión en Claude una vez por proyecto
- Al terminar, la VM puede suspenderse con
vagrant suspend
- Claude recibe privilegios
sudo dentro de la VM para realizar tareas como las siguientes
- Ejecutar la API de una web app y revisarla con
curl
- Instalar un navegador, inspeccionar manualmente la app y generar pruebas E2E
- Configurar una BD PostgreSQL y probar migraciones
- Construir y ejecutar imágenes Docker
- Gracias a este entorno, Claude puede encargarse por sí solo de ejecutar comandos, verificar salidas y repetir procesos
Rendimiento y seguridad
- En un entorno Linux + VirtualBox hay suficiente margen de recursos y no hay retrasos en la sincronización de archivos
- Elementos que sí se pueden proteger
- Daños al sistema de archivos por errores accidentales
- Instalación indiscriminada de paquetes y cambios de configuración
- Elementos que no se pueden proteger
- Eliminación de la carpeta del proyecto (sincronización bidireccional)
- Ataques que exploten vulnerabilidades de escape de VM
- Problemas a nivel de red
- Exfiltración de datos (la VM tiene acceso a internet)
- Esta configuración está pensada para prevenir accidentes, no para defenderse de ataques avanzados
- Como el proyecto está basado en Git, incluso si hay daños es fácil recuperarlo; si hace falta un aislamiento más estricto, puede usarse sincronización unidireccional con
rsync
Conclusión
- Tras resolver el bug de CPU de VirtualBox, se logró un entorno de ejecución sin fricción
- Claude Code puede ejecutarse libremente dentro de un sandbox completo en una VM
- Si ocurre algún problema, basta con eliminar y recrear la VM, y la reproducibilidad queda garantizada con un solo Vagrantfile
- Si se va a usar la bandera
--dangerously-skip-permissions, se recomienda encarecidamente montar un entorno aislado como este
1 comentarios
Comentarios de Hacker News
Si usas Claude por un tiempo, al final por la fatiga de decisión (decision fatigue) después de unos meses simplemente terminas presionando Enter
Por eso siento que es mucho más seguro ejecutarlo en modo YOLO pero con un entorno sandbox ya preparado
En Ubuntu 22.04 armé un sandbox en capas combinando bubblewrap y Landlock LSM
Landlock restringe el acceso al sistema de archivos con una lista blanca y también controla el acceso a puertos TCP
bubblewrap aísla los namespaces de montaje para crear un /tmp por proyecto y ocultar claves secretas
Con dnsmasq configuré una lista blanca de DNS para que solo se resuelvan los dominios necesarios
Gracias a esta estructura se redujo el estrés de tener que vigilar al agente todo el tiempo
Tener que aprobar una por una las piezas de elisp que sugería Claude fue una experiencia muy cansada
Incluso cuidando solo que no instalara cualquier cosa rara con comandos Bash, igual fue pesado
/sandboxSoy Srini de Docker
Muchos desarrolladores están usando Docker para resolver este problema, y también hemos recibido mucho feedback sobre las limitaciones de Docker-in-Docker
Por eso lanzamos de forma experimental Docker Sandboxes como preview
Todavía está en una etapa temprana, pero estamos desarrollando la siguiente versión sobre MicroVM para evitar el problema de Docker-in-Docker
Quisiera saber si Claude puede levantar otros contenedores sin privilegios dentro de Docker Sandbox
Parece que la mayoría quiere evitar correr una VM local por su cuenta, pero no entiendo por qué
En realidad una VM local es lo más simple y resuelve todos los problemas
Si usas Docker en Mac, de todos modos ya corre sobre una VM Linux, así que solo estás a un nivel de distancia del entorno real
También puedes entrar directo por SSH desde el IDE para revisar el código
Yo activo la opción
--dangerously-skip-permissionsy manejo todos los cambios como PRsLlevo meses usándolo junto con workmux, y es muy eficiente porque permite manejar varios PRs al mismo tiempo
La razón por la que es mejor que una VM en la nube es que, si levantas varios contenedores a la vez, consumen mucha memoria
Tener una VM potente en la nube encendida 24/7 sale demasiado caro en costos
Una IA maliciosa ni siquiera necesita explotar una vulnerabilidad de escape de VM; puede agregar código arbitrario a un Vagrantfile para obtener acceso al host
Incluso si solo te preocupan errores simples, si Claude modifica un hook de commit, cuando eso se ejecute puede causar problemas
Me queda claro que mantener un aislamiento completo y al mismo tiempo desarrollar cómodamente es realmente difícil
Por ejemplo, usando un montaje de volumen de Docker para que solo pueda modificar la carpeta
sandbox/y sin acceso a.gitYo trabajo tomando un snapshot, levantando una VM pequeña para ejecutar al agente y luego comparando de nuevo el snapshot
Nunca hago sincronización automática porque destruye por completo el objetivo del aislamiento
Estoy probando otro enfoque: interceptar lo que Claude intenta ejecutar
Shannot captura la intención antes de ejecutar y intercepta las llamadas al sistema en un sandbox de PyPy
Los comandos y escrituras de archivos solo quedan en el log y no se ejecutan realmente
Solo se ejecutan después de que el usuario los revisa y aprueba en una TUI
La diferencia con una VM es que la VM deja correr libremente en un entorno completamente aislado, mientras que Shannot aplica cambios al sistema real basados en aprobación humana
Sirve para tareas como modificar servidores
También tiene integración con Claude MCP, ejecución remota por SSH y funciones de checkpoint/rollback
Al final se detiene en la primera solicitud de aprobación, así que el agente no puede explorar libremente
Lo que yo quiero es que el agente pueda intentar todo hasta el final sin detenerse a la mitad y luego evaluar el resultado
Así se ahorra mucho tiempo
Es parecido al modo de extensión del sistema nativo de Mac de Leash, pero todavía no tiene un modo de aprobación interactiva completo
Es un proyecto interesante
Cuando se acumula la fatiga de aprobación, terminas queriendo usar
--dangerously-skip-permissionsPor eso yo ejecuto Claude Code dentro de un devcontainer
El acceso a archivos está limitado al repositorio y la red solo permite una lista blanca
Después lo generalicé con docker compose, y lo siguiente será agregar soporte para otros agentes como Codex u OpenCode
Quiero forzar el enrutamiento de red a través de un proxy en el host para mejorar el logging y control
Por ahora lo manejo temporalmente con iptables
Sigue en etapa temprana, pero funciona bastante bien
Código: agent-sandbox
Estoy usando mitmproxy como proxy de red; todavía no está perfecto, pero casi
Claude configuró el sistema por sí solo durante horas y terminó la app
Nosotros no escribimos ni una sola línea de código y el resultado fue sorprendentemente bueno
Siento que la velocidad del desarrollo con IA es realmente impresionante
Mi solución es simple
Así, el comando npx se ejecuta de forma transparente dentro de un sandbox de Bubblewrap, exponiendo solo el directorio actual
Se puede implementar con unas cuantas líneas de shell POSIX puro
sandbox-run
Otro inconveniente es que, una vez que sueltas los privilegios, no puedes recuperarlos
Yo simplemente lo meto en un contenedor LXC sin privilegios y ya
Mi modelo de amenaza no son ataques complejos, sino una situación como “borrar accidentalmente mi directorio home”
En mi proyecto pongo scripts de utilidad en el directorio
run/y levanto contenedores sobre composeEl devcontainer está mapeado con el directorio y los volúmenes del host
Claude maneja bien la configuración de servicios, la actualización de scripts y el diagnóstico de problemas en runtime
No hay integración con navegador, pero creo que con Playwright o Puppeteer bastaría
Me interesa saber qué opinan del sandboxing integrado de Claude Code
Enlace a la documentación oficial
Claude Code tiene una vía de escape para desactivar el sandbox cuando hace falta
Si un comando falla por las restricciones del sandbox, Claude puede analizar la causa y reintentar con
dangerouslyDisableSandboxQue el agente pueda desactivar el sandbox por sí mismo parece una vulnerabilidad, así que me pregunto si en ese caso existe algún proceso de aprobación del usuario
Issues relacionados: #14268, #13583, #10089