Saltar al contenido
Curso Claude Code
21/57 Configuración y permisos Sandbox de Claude Code en WSL2 y Linux
Tu lectura Quedan 18 min
Lección 21 de 57 · Configuración y permisos

Sandbox de Claude Code en WSL2 y Linux

18 min de lectura Claude Code 2.1.283

Hola, bienvenido. En la lección anterior terminamos con una idea muy importante: una regla deny de Bash frena la forma habitual de un comando, pero no es una barrera de seguridad, porque se compara con el texto que escribe Claude. En esta lección vamos a poner esa barrera. Veremos qué es el sandbox de Claude Code y qué aísla, qué tienes que instalar en WSL2 y en Linux para usarlo, cómo se maneja desde /sandbox, cómo activarlo en claude-tasks sin romper los comandos de Sail y qué límites tiene, que también los tiene.

¿Por qué es tan distinto de lo que hemos visto hasta ahora? Porque las reglas de permisos y el clasificador de auto mode deciden antes de que un comando se ejecute, mirando el texto del comando y, en auto mode, el juicio de un segundo modelo. El sandbox actúa después, sobre el proceso que ya está corriendo: es el sistema operativo el que impide que ese proceso, y cualquier proceso que lance, escriba fuera del proyecto o se conecte a un dominio que no has aprobado. La documentación lo resume muy bien: esa barrera se mantiene sea cual sea el comando que haya elegido el modelo, y aunque un comando permitido haga más de lo que su nombre sugiere. Y tiene un segundo efecto que vas a notar en el día a día: como el sistema operativo pone el límite, Claude Code puede dejar que la mayoría de los comandos se ejecuten sin pedirte permiso.

Qué aísla el sandbox

El sandbox de Claude Code se aplica a los comandos de las herramientas Bash, PowerShell y Monitor, y a todos los procesos que esos comandos lanzan. Trabaja en 2 capas independientes, el sistema de archivos y la red.

En el sistema de archivos, por defecto, los comandos pueden escribir en el directorio de trabajo y sus subcarpetas, en un directorio temporal propio de tu usuario, al que apunta $TMPDIR dentro del sandbox, y en los directorios que hayas añadido con --add-dir o /add-dir. No pueden modificar nada fuera de ahí, ni tu ~/.bashrc ni los binarios del sistema. Para leer, en cambio, tienen acceso a todo el ordenador salvo lo que se deniega expresamente, y eso incluye por defecto archivos de credenciales como los de ~/.ssh/. Se puede cerrar con el ajuste sandbox.credentials o con denyRead, aunque eso queda fuera de lo que vamos a configurar en el curso. Además, dentro de lo que sí pueden escribir, el sandbox protege los archivos de los que Claude Code carga configuración y código, como los settings de .claude, sus carpetas skills, agents, commands y hooks, el .mcp.json o los hooks y el config de .git, para que un comando no pueda darse permisos a sí mismo.

En la red, el tráfico pasa por un proxy que corre fuera del sandbox y que no deja pasar ningún dominio por defecto. La primera vez que un comando necesita un dominio nuevo, Claude Code te pide aprobación: con Yes lo permite durante el resto de la sesión, y con Yes, and don't ask again guarda una regla WebFetch(domain:...) en tu configuración local para las siguientes. En auto mode funciona algo distinto, desde la versión 2.1.271: Claude indica en el propio comando los dominios que necesita, y el clasificador los revisa junto con el comando.

Y aquí está la conexión con las lecciones anteriores. Las rutas de tus reglas Read(...) en deny se añaden a la lista de lecturas que el sandbox deniega, así que el Read(./.env) que pusimos en settings.json pasa a aplicarse a nivel del sistema operativo. Recuerda que la regla sola no llegaba a un grep -r sobre todo el proyecto ni a un script que abre el archivo por su cuenta. Con el sandbox activo, ese grep o ese script corren dentro del sandbox, y el sistema operativo no les deja leer el .env. Eso es lo que significa que el sandbox llega donde una regla deny no llega.

Conviene no confundirlo con un modo de permiso. Los modos deciden si una llamada a una herramienta se ejecuta y si te preguntan antes; el sandbox restringe a qué puede acceder un comando de Bash una vez que se ejecuta. Por eso se combinan, y la documentación propone justo eso: usar las 2 capas a la vez, porque las restricciones del sandbox se siguen aplicando aunque un prompt injection consiga engañar a Claude.

Lo que queda de esta lección
  1. 02Qué instalar en WSL2 y Linux
  2. 03El panel /sandbox
  3. 04Activar el sandbox en claude-tasks
  4. 05Los límites del sandbox
Sigue leyendo con tu suscripción El curso completo, con el certificado y el foro con los planes trimestral y anual, está incluido en la suscripción. Ver los planes