Sandboxing y entornos aislados

Esta es la capa más fuerte de la lección anterior: la que impone el sistema operativo. Mientras los permisos razonan sobre el texto de un comando antes de correrlo, el sandbox pone un muro alrededor del proceso mientras corre, y ese muro aguanta aunque una inyección engañe al modelo.

Qué hace el sandbox del Bash tool

Con el sandbox activo, Claude ejecuta la mayoría de comandos sin pararse a preguntar, porque el SO garantiza que no pueden salirse de unos límites que defines tú:

• Filesystem: por defecto solo puede escribir en el directorio de trabajo. Puede leer casi todo el disco salvo lo que vetes. Ojo: por defecto aún puede leer credenciales como ~/.aws/credentials o ~/.ssh/; añádelas a denyRead para taparlas.
• Red: ningún dominio está pre-permitido. La primera vez que un comando necesita un dominio nuevo, Claude te pide aprobación; pre-autoriza los habituales con allowedDomains.

Lo importante: estos límites los hereda cualquier subproceso (un npm, un terraform, un script de Python), no solo las herramientas internas de Claude. Por eso es más fuerte que las reglas Read/Edit, que no alcanzan a procesos arbitrarios.

Cómo activarlo

/sandbox

abre un panel donde eliges modo (auto-allow o permisos normales) y ves la config resuelta. Seleccionar modo ahí escribe en .claude/settings.local.json (solo este proyecto). Para activarlo en todos tus proyectos, en tu ~/.claude/settings.json:

{ "sandbox": { "enabled": true } }

Si un subproceso necesita escribir fuera del proyecto (p.ej. ~/.kube), ábrelo de forma quirúrgica:

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

Plataformas (importante en Windows)

• macOS: funciona de serie (usa Seatbelt), nada que instalar.
• Linux y WSL2: necesita bubblewrap y socat (sudo apt-get install bubblewrap socat).
• Windows nativo: no soportado. Si trabajas en Windows, ejecuta Claude Code dentro de WSL2 para tener sandbox.

Cuándo subir un peldaño: entornos aislados

El sandbox del Bash tool es la opción ligera del día a día. Para correr Claude desatendido o con bypassPermissions, no basta: aísla todo el proceso en un dev container, un contenedor o una VM sin acceso a tu host ni a tus credenciales. Ahí sí tiene sentido saltarse los prompts, porque el daño posible lo contiene el entorno.

Resumen de "cuánta jaula necesito": revisar a mano → default/acceptEdits. Menos fricción con red de seguridad → sandbox del Bash tool. Autonomía total → contenedor/VM aislado con la sesión dentro.

Un límite que conviene saber

El sandbox reduce el riesgo, no es aislamiento perfecto. El filtro de red decide por el nombre de dominio sin inspeccionar el tráfico TLS, así que permitir dominios muy amplios (github.com) puede abrir vías de exfiltración. Mantén la lista de dominios estrecha y, si tu modelo de amenaza lo exige, un proxy propio que inspeccione TLS.

Cierre del curso y de la base

Tienes la base completa del plan de estudios:

• Intro: qué es Claude Code y cómo conducir una sesión.
• CLAUDE.md y memoria: un contrato permanente y la memoria del agente.
• Este curso: qué puede hacer, mediante permisos, settings versionados y un sandbox real.

A partir de aquí dejas de configurar y empiezas a extender Claude a tu medida: slash commands y skills propias, subagentes y hooks. Ese es el siguiente nivel del plan.

Fuente oficial: Sandboxing · Sandbox environments