El sandbox de Claude Code, en llano

El sandbox es un límite que tu sistema operativo hace cumplir alrededor de los comandos de shell que ejecuta Claude. Tú decides a qué archivos y dominios de red pueden llegar esos comandos. Como el sistema operativo aplica los límites mientras el comando se ejecuta, Claude Code puede lanzar comandos dentro del sandbox sin pedirte aprobación en cada uno. Viene desactivado por defecto.

Qué cubre y qué no

El sandbox envuelve los comandos de shell (Bash, PowerShell y los comandos de Monitor) y los procesos que lanzan. Todo lo demás sigue otras reglas:

• Las herramientas integradas de archivos y web (Read, Edit, Write, WebFetch, WebSearch) siguen las reglas de permisos, no el sandbox. Una restricción de lectura del sandbox no detiene a la herramienta Read.
• Los hooks, los servidores MCP locales, los servidores LSP y comandos auxiliares como el de tu línea de estado se ejecutan con tu acceso completo.
• Los comandos que escribes tú mismo en el prompt de shell ! normalmente se ejecutan fuera del sandbox.

Funciona en macOS, Linux y WSL2. En Windows nativo, Claude Code ejecuta los comandos sin sandbox; la documentación dice que uses WSL2 si quieres el sandbox en un equipo Windows. En Linux y WSL2 necesita dos paquetes, bubblewrap y socat, por ejemplo sudo apt-get install bubblewrap socat en Ubuntu o Debian.

Actívalo

/sandbox

El panel tiene pestañas para Mode (cómo se aprueban los comandos del sandbox), Overrides (si un comando que falla puede volver a ejecutarse fuera del sandbox) y Config (los ajustes en vigor). En Linux o WSL2 también te dice si falta alguna dependencia. También puedes poner sandbox.enabled en true en un archivo de ajustes como ~/.claude/settings.json para activarlo en todos los proyectos; mira qué archivo de ajustes manda.

Una cosa importante: si el sandbox no puede arrancar porque falta una dependencia o la plataforma no es compatible, Claude Code por defecto ejecuta los comandos sin sandbox. Poner sandbox.failIfUnavailable en true hace que salga al arrancar en su lugar.

A qué llegan los comandos por defecto

• Escritura: el directorio de trabajo, un directorio temporal por usuario y los directorios que hayas añadido.
• Lectura: casi todo el equipo, incluidos archivos de credenciales como ~/.ssh y ~/.aws/credentials. La lectura no está restringida si tú no la restringes.
• Red: sin salida directa. Las conexiones pasan por un proxy en tu equipo que comprueba cada host contra tus dominios permitidos, que empiezan vacíos. Lo que pasa con un host que no está en la lista depende de tu modo de permisos: en modo manual te sale un aviso, en modo automático se rechaza salvo que el comando nombrara el host y el clasificador lo aprobara.
• Variables de entorno: heredadas de Claude Code, incluidos los secretos que haya en su entorno.

Comprueba que funciona

Pídele a Claude que ejecute estos dos comandos. Escribirlos tú en el prompt ! no prueba el sandbox.

touch ~/sandbox-probe
curl --noproxy '*' https://example.com

Dentro del sandbox el primero falla (Operation not permitted en macOS, Read-only file system en Linux y WSL2) y el segundo falla con Could not resolve host. Si Claude pide repetir un comando fallido fuera del sandbox, recházalo. Si el touch funciona, borra el archivo y revisa /sandbox.

Dos modos

• Auto-allow: un comando que se ejecuta dentro del sandbox se aprueba sin aviso. Las reglas de denegación siguen aplicándose, y las reglas de preguntar como Bash(git push *) siguen avisando. Ojo: esto incluye comandos que cambian archivos dentro del límite, incluso en modo de permisos manual, donde las herramientas de edición preguntarían.
• Permisos normales: todos los comandos Bash pasan por el flujo normal de permisos, aunque estén en el sandbox. Más control, más avisos.

El modo auto-allow del sandbox no es lo mismo que el modo de permisos llamado automático. Auto-allow aprueba un comando porque el sandbox lo contiene; el modo automático usa un clasificador que revisa las acciones. Funcionan por separado y se pueden combinar. Mira los modos de permisos.

La puerta de escape

Cuando un comando falla dentro del sandbox, Claude puede pedir repetirlo fuera. Quién lo aprueba depende de tu modo de permisos, y una regla de permitir que coincida con el comando también aprueba el reintento sin aviso. Si no quieres que exista ese camino, pon "allowUnsandboxedCommands": false en los ajustes del sandbox (la pestaña Overrides lo llama strict sandbox mode). Los comandos que coinciden con excludedCommands también se ejecutan fuera del sandbox.

Amplíalo o redúcelo

Las herramientas que deben escribir fuera del directorio de trabajo necesitan una ruta concreta, en vez de excluirlas del sandbox:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

Para que los comandos del sandbox no puedan leer todo tu directorio personal pero sí el proyecto, pon esto en el .claude/settings.json del proyecto (ahí, . significa la raíz del proyecto):

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

Las rutas del sandbox usan las convenciones habituales (~/.kube cuelga de tu directorio personal, /tmp/build es absoluta), distintas del estilo de rutas de las reglas de permisos Read y Edit. El acceso a la red se amplía con network.allowedDomains.

Sus límites

La documentación es clara: el sandbox reduce el riesgo, pero no es un aislamiento completo.

• El proxy de red decide por el nombre del host y por defecto no inspecciona el tráfico cifrado. Permitir un dominio amplio como github.com puede crear un camino por el que salgan datos.
• Permitir un socket Unix como el de Docker puede entregar de hecho el equipo anfitrión. Un acceso de escritura amplio a directorios de tu PATH o a archivos como .bashrc puede acabar en código ejecutándose fuera del límite.
• Un sandbox eficaz necesita aislamiento de archivos y de red. Comprueba que un allowWrite amplio, un dominio amplio o una entrada en excludedCommands no deshaga una restricción del otro lado.

El sandbox funciona junto a las reglas de permisos, no en su lugar: las reglas deciden qué herramientas puede usar Claude y se comprueban antes de que la herramienta se ejecute, mientras que el sistema operativo hace cumplir el sandbox sobre el proceso en marcha. Para cualquier cosa de seguridad quieres las dos. Mira las buenas prácticas para ver cómo encajan las reglas de denegación, los hooks y el sandbox, y depura la configuración si un ajuste parece ignorado. La sección de problemas de la documentación cubre herramientas que necesitan un trato especial, como docker y git por SSH.

Esta página sigue la documentación de sandboxing de Anthropic tal como la leemos en octubre de 2026. No tenemos relación con Anthropic. La escribimos a partir de la documentación y no hemos probado todos los casos (no pudimos probar el sandbox en todas las plataformas). Los ajustes y la compatibilidad por plataforma cambian entre versiones, y donde esta página y la documentación no coincidan, manda la documentación. Esta página es información general, no una auditoría de seguridad de tu configuración.

La skill gratis loop-stop da a las tareas largas un límite y una regla de parada. Si quieres una segunda mirada a tu CLAUDE.md y a tus ajustes, el Tune-Up Kit es una lista de comprobación para eso (la ficha está en inglés).