Hay un momento, cuando llevas suficientes horas trabajando con un agente de código, en que dejas de leer los prompts de permiso. Los apruebas en automático. git status, sí. npm test, sí. rm -rf node_modules, sí, claro, obvio. Y entonces te das cuenta de que el mecanismo que estaba ahí para protegerte se convirtió en un trámite.
La respuesta natural es quitarlo: --dangerously-skip-permissions y a trabajar. La bandera se llama así por algo. Pero la pregunta correcta no es si quitas los prompts, sino qué pones en su lugar.
Anthropic acaba de publicar una página que compara las opciones de aislamiento para Claude Code, y vale la pena leerla con calma porque ordena algo que la mayoría tenemos revuelto: permisos y aislamiento no son lo mismo, y resuelven problemas distintos.
Dos preguntas que se confunden todo el tiempo
Los permission modes contestan: ¿esta acción se ejecuta, y te pregunto antes?
El aislamiento contesta: una vez que se ejecuta, ¿hasta dónde alcanza?
Son ejes independientes. Puedes tener permisos estrictos sin aislamiento —cada acción te pregunta, pero cuando dices que sí, la acción tiene tu máquina entera— y puedes tener aislamiento fuerte sin permisos, que es exactamente lo que quieres para correr un agente desatendido.
Cuando pasas --dangerously-skip-permissions, eliminas el primer eje casi por completo. Claude sigue preguntando por unas pocas cosas: reglas ask explícitas, herramientas MCP marcadas como requiresUserInteraction, y borrados que apunten a / o a tu home. Fuera de eso, actúa. Sin prompts que atajen un error, lo único que te queda es el límite de aislamiento que hayas puesto. Si no pusiste ninguno, no tienes nada.
(Detalle que me gustó: en Linux y macOS, Claude Code se niega a arrancar con esa bandera si corres como root. Alguien pensó en el caso.)
El auto mode es distinto: reemplaza el prompt por un clasificador que revisa cada acción. Es un control por acción, útil, pero no es una frontera. Sigue siendo software decidiendo, no el kernel impidiendo.
Seis niveles, y el corte que importa
La tabla de la doc lista seis enfoques. Ordenados por lo que aíslan:
| Enfoque | Qué queda adentro | ¿Docker? |
|---|---|---|
| Bash sandboxeado (built-in) | solo comandos Bash | No |
| Sandbox runtime | el proceso completo | No |
| Dev container | entorno de desarrollo | Sí |
| Contenedor propio | entorno de desarrollo | Sí |
| Máquina virtual | sistema operativo completo | No |
| Claude Code on the web | VM gestionada por Anthropic | No |
El corte importante está entre el primer renglón y todos los demás.
El sandbox de Bash —el que configuras con /sandbox— usa primitivas del sistema operativo para restringir filesystem y red de cada comando que Claude ejecuta. Funciona bien y es lo que deberías tener prendido para el día a día. Pero restringe únicamente Bash.
Read, Edit, WebFetch corren dentro del proceso de Claude Code, sin sandbox. Los servidores MCP y los hooks son procesos aparte que corren libres en tu host. O sea: tienes un agente al que le amarraste una mano.
Para trabajo interactivo eso está bien; las permission rules de path y dominio cubren el resto y tú estás ahí viendo. Para trabajo desatendido no alcanza, y la doc lo dice sin rodeos.
El sandbox runtime: contenedor sin contenedor
Esta es la opción que menos gente conoce y la que probablemente más valga para quien trabaja en una laptop.
@anthropic-ai/sandbox-runtime envuelve un proceso entero en el mismo aislamiento que usa el Bash sandbox: Seatbelt en macOS, bubblewrap en Linux y WSL2. Si arrancas Claude Code a través del runtime, todo —tools, hooks, servidores MCP— queda del lado adentro de la frontera. Sin Docker.
Está marcado como research preview y el formato de configuración puede cambiar, así que trátalo como lo que es.
En macOS no necesitas instalar nada. En Linux y WSL2 necesitas bubblewrap, socat y ripgrep (Claude Code trae el suyo, pero el runtime standalone lo busca en tu PATH).
Lo que hay que entender antes de lanzarlo es que por defecto niega la red completa y confina las escrituras a un puñado de rutas internas. No es un sandbox permisivo que tú cierras; es uno cerrado que tú abres. La configuración vive en ~/.srt-settings.json.
Como mínimo necesitas dar escritura a:
- el directorio de tu proyecto
~/.claudey~/.claude.json/tmp, donde Claude Code escribe archivos de runtime
Y abrir estos dominios:
api.anthropic.com— y ojo, también si usas otro proveedor, porque el chequeo de seguridad de dominios de WebFetch le pega a ese endpoint salvo que pongasskipWebFetchPreflight: trueclaude.aiyplatform.claude.com, que necesita el login OAuth y el refresco de token. Si te autenticas con API key, esos dos los puedes quitar
En un entorno limpio sobre Linux hay un detalle que te va a morder: el runtime aplica los permisos de escritura solo a rutas que ya existen. Crea la configuración antes del primer arranque.
Y ya con el settings en su lugar:
El mismo comando sirve para envolver un servidor MCP suelto o cualquier otro proceso auxiliar, que me parece la parte más subestimada de todo esto.
Lo que bloquea solo, y por qué
Sin que le configures nada, el runtime niega las escrituras de mayor riesgo. denyWrite gana siempre sobre allowWrite. En la raíz del proyecto bloquea .git/hooks, bloquea .git/config salvo que pongas filesystem.allowGitConfig: true, y bloquea .mcp.json, .claude/commands, .claude/agents y los archivos de arranque de tu shell.
La lógica detrás de esa lista es la parte interesante. Todos esos archivos tienen algo en común: se ejecutan la próxima vez, fuera del sandbox. Una sesión aislada que pueda escribir un git hook o un .mcp.json acaba de plantar código que va a correr sin aislamiento cuando vuelvas a abrir el proyecto. El sandbox no serviría de nada si dejara esa puerta.
Por eso la doc insiste: si tus grants de escritura incluyen otras rutas de donde Claude Code carga configuración, agrégalas tú a denyWrite.
Hay dos trampas que conviene tener presentes.
La primera es de plataforma. En macOS los denies se checan en el momento de escribir, así que cubren archivos anidados y repositorios que nazcan durante la sesión. En Linux y WSL2 la lista se construye una sola vez al arrancar: cubre bien la raíz del proyecto, hace un escaneo superficial de copias anidadas que existan en ese momento, y no cubre nada que la sesión cree después. Un git init o un git clone a media sesión queda fuera de la lista.
La segunda es peor porque es silenciosa. Si tu ~/.srt-settings.json no es válido, el runtime arranca de todos modos: bloquea la red y confina las escrituras a rutas internas como /tmp/claude y ~/.claude/debug. Un arranque limpio no prueba que tu configuración cargó. Solo si pasas --settings explícitamente, el runtime se niega a arrancar cuando el archivo falla.
Si de esta sección te llevas una sola cosa: verifica que tus reglas se aplicaron, no que el proceso arrancó.
Cuando sí quieres el contenedor
El dev container es un contenedor de Docker con tu proyecto montado, gestionado por VS Code o un editor compatible. El repo de claude-code publica uno de ejemplo con un firewall de iptables default-deny, pensado para que lo copies a tu repositorio y le ajustes el allowlist, la imagen base y la versión fijada de Claude Code. Como el firewall bloquea el egress no aprobado, una configuración así sí soporta correr con --dangerously-skip-permissions.
El contenedor propio es el camino de siempre para quien ya tiene infraestructura: tus políticas de red, tus volúmenes, tus perfiles de seccomp. Y puedes anidar el Bash sandbox adentro para tener restricciones por comando encima de la frontera del contenedor —en contenedores no privilegiados eso pide el setting de nested sandbox.
La máquina virtual es la separación más fuerte: kernel propio, y en microVMs como Firecracker hardware virtualizado propio. La doc la reserva para tres casos concretos: código que no es tuyo y no confías, políticas de seguridad que exigen separación a nivel kernel, y requisitos de cumplimiento que ningún enfoque a nivel host satisface. Mencionan Docker Sandboxes, que da un microVM con su propio daemon y sync de workspace, gratis y sin Docker Desktop.
Y Claude Code on the web, que corre cada sesión en una VM aislada de Anthropic, con un proxy de red que impone un allowlist por defecto y otro proxy que guarda tu token de GitHub fuera del sandbox mientras emite credenciales acotadas hacia adentro. Ese diseño de dos proxies me parece la idea más elegante de toda la página: el secreto de verdad nunca entra al ambiente donde corre el agente.
Lo que ninguna opción arregla
La doc pone dos advertencias que conviene no saltarse.
El aislamiento reduce el impacto de una brecha; no la elimina. Cualquier enfoque que permita salida a la red puede filtrar lo que el agente alcance a leer. Cualquier enfoque que monte tu directorio de proyecto como escribible permite modificar ese código. Si tu modelo de amenaza incluye exfiltración, el sandbox por sí solo no es la respuesta: la política de egress sí.
Y la segunda, que se olvida seguido: el aislamiento no cambia lo que se le envía al modelo. Tus prompts y los archivos que Claude lee viajan a la API con sandbox o sin él.
Qué haría yo
Para trabajo del día a día en tu máquina, con tu código: /sandbox prendido. Baja los prompts sin que tengas que pensar y no le cuesta nada a tu flujo.
Para dejar a un agente corriendo solo, con permisos abiertos: sandbox runtime si quieres quedarte fuera de Docker, dev container si ya vives en Docker. Y después de la corrida, revisa las rutas que dejaste escribibles —en Linux, revisa además lo que la sesión haya creado.
Para código que no conoces: VM o Claude Code on the web. Aquí no hay término medio que valga.
Si administras un equipo, hay un matiz que la doc deja claro y que ahorra discusiones: lo único que Claude Code puede imponer por sí mismo es el Bash sandbox, vía managed settings o server-managed settings en Claude.ai. Los contenedores y las VMs son convención, no frontera —para volverlos obligatorios necesitas las herramientas de gestión de dispositivos o de allowlisting de software de tu organización. Un .devcontainer/ en el repo documenta la intención; no la hace cumplir.
Y cuando el agente no corre en tu laptop
Todo lo anterior asume una premisa: que el agente vive en tu máquina y el problema es protegerla de él.
Hay un montón de casos donde esa premisa no aplica. Un agente que corre desde tu backend cuando un usuario aprieta un botón. Un worker que procesa una cola. Un endpoint que recibe código de alguien más y lo ejecuta. Ahí no hay laptop que aislar y ninguna de las seis opciones de la tabla te sirve tal cual — necesitas sandboxes que nazcan y mueran por request, no un contenedor que tú administres.
Es exactamente el problema en el que estamos trabajando con EasyBits Sandbox: entornos aislados y efímeros que levantas por API para correr código de agentes, con el filesystem y el egress acotados desde el arranque. La misma idea que la doc de Anthropic aplica a tu terminal, pero del lado del servidor y sin que tengas que operar la infraestructura.
Si estás construyendo algo donde un agente ejecuta código que no escribiste tú, date una vuelta por easybits.cloud. Y si prefieres verlo funcionando antes que leer sobre ello, en el canal de YouTube vamos publicando lo que aprendemos corriendo esto en producción — incluida la parte incómoda de qué se rompe cuando le das demasiado permiso a un agente.
Referencia: este post comenta Choose a sandbox environment de la documentación oficial de Claude Code. Las dos páginas que conviene leer junto a ella son Sandboxing, para configurar el Bash sandbox, y el README de @anthropic-ai/sandbox-runtime, que trae el esquema completo de configuración.
Abrazo. bliss. 🤖
