Sesgo declarado, como siempre: enseño Claude Code a equipos de ingeniería, así que cualquier cambio en cómo se aísla lo que Claude ejecuta —y en quién decide esa política— me toca de lleno. Precisamente por eso esta pieza va de hechos verificables y de qué te toca decidir, no de vender dos flags de configuración como una revolución.
Esta semana la portada se la lleva Claude Opus 5, el nuevo modelo por defecto. Pero en la misma tanda de versiones hay un cambio más callado que solo importa si dejas correr a Claude con autonomía: el sandbox de Bash gana dos mandos para afinar sus dos capas de aislamiento por separado.
Los hechos
El sandbox de Bash tiene dos capas independientes: aislamiento de ficheros (qué rutas puede leer y escribir un comando) y aislamiento de red (a qué dominios puede conectarse). Según el changelog oficial de Claude Code, esta semana cada capa estrena un ajuste:
sandbox.filesystem.disabled(v2.1.216, 20 de julio de 2026): "salta el aislamiento de ficheros manteniendo el control de la salida de red". Ponlo atruey los comandos del sandbox pasan a tener lectura y escritura sin restricciones sobre el sistema de ficheros del host, pero su tráfico de red sigue confinado a los dominios que hayas permitido. Está apagado por defecto y requiere la v2.1.216 o superior.sandbox.network.strictAllowlist(v2.1.219, 24 de julio de 2026): "deniega los hosts que no están en la lista para los comandos del sandbox sin preguntar". Cambia el comportamiento por defecto de la capa de red, que era preguntarte la primera vez que un comando necesita un dominio nuevo. Con este ajuste activo, el host no permitido se bloquea en silencio en lugar de lanzarte un prompt.
Ninguno de los dos es un experimento en preview: son ajustes en la rama estable. Para tenerlos, actualiza.
Por qué separar las dos capas
La documentación es explícita sobre la postura recomendada: un sandbox efectivo necesita las dos capas. Sin aislamiento de red, un agente comprometido podría exfiltrar ficheros sensibles como tus claves SSH; sin aislamiento de ficheros, podría plantar un backdoor en el sistema para después ganar acceso a la red. Por eso, de fábrica, un comando del sandbox solo puede escribir en tu directorio de trabajo y en el temporal de la sesión, y la red no tiene ningún dominio preaprobado: el primer intento de conectarse a un host nuevo te pide permiso.
Lo que hacen los dos ajustes de esta semana es dejarte mover cada palanca por su cuenta, en direcciones opuestas:
strictAllowlistaprieta la red: en vez de preguntar por cada host nuevo, lo deniega. Preapruebas lo que necesites conallowedDomainsy todo lo demás queda fuera, sin un prompt que interrumpa.filesystem.disabledafloja los ficheros: apagas la capa de ficheros entera y te quedas solo con el control de red. Es para cuando lo que te importa es a dónde se conecta un comando, no qué escribe.
Qué te afecta, según quién seas
Si dejas correr a Claude sin vigilancia (CI, sesiones en la nube, auto mode).
Aquí strictAllowlist es la pieza interesante. Un prompt de red no tiene sentido
cuando no hay nadie delante para contestarlo: o cuelga la tarea o alguien acaba
aprobando a ciegas. Con la lista estricta, defines tu allowlist de dominios una
vez y cualquier conexión fuera de ella falla en el acto, sin bloquear la
sesión esperando tu clic. Es justo la disciplina de egress que quieres antes de
soltar agentes a trabajar solos, y encaja con cómo montamos ejecuciones
desatendidas en el curso de orquestar agentes.
Si el aislamiento de ficheros te rompe herramientas. Hay toolchains que
escriben en medio sistema (cachés en el home, ficheros de estado fuera del
proyecto) y pelean con la capa de ficheros del sandbox. filesystem.disabled te
deja quedarte con el guardarraíl que de verdad te importa —el de red— sin seguir
librando esa batalla. Pero léelo como lo que es: un intercambio de seguridad,
no un atajo gratis. Con la capa de ficheros apagada y los comandos
auto-aprobados, un comando puede escribir en tu .bashrc, en un ejecutable del
$PATH o en tu propio ~/.claude/settings.json y usar eso para ampliarse el
acceso en la siguiente pasada. Además dejan de aplicarse las protecciones de
lectura de esa capa (filesystem.denyRead y los ficheros de sandbox.credentials;
el borrado de variables de entorno sí sigue). Actívalo solo para cargas de
trabajo en las que confías.
Si administras Claude Code para un equipo. Dos matices que te ahorran un
susto. El primero: filesystem.disabled no se puede activar desde los settings
del proyecto (.claude/settings.json), solo desde tus settings de usuario, los
managed settings o el flag --settings. Es decir, un repo que te clonas no
puede apagarte el aislamiento de ficheros a tus espaldas. El segundo: si
despliegas restricciones de sandbox por managed settings, ese candado se
mantiene: cuando la organización configura sandbox.filesystem, solo la propia
organización puede desactivarlo. Decidir qué se permite tocar sin preguntar y
qué se cierra sin excepción —en ficheros y en red— es exactamente el tipo de
política que trabajamos en el curso de
permisos, settings y seguridad.
Qué llevarte
- El sandbox tiene dos capas y ahora se afinan por separado: ficheros y red son independientes; esta semana cada una gana un mando.
strictAllowlist(v2.1.219): deniega los hosts fuera de tu allowlist sin preguntar. Ideal para ejecuciones desatendidas, donde un prompt de red solo cuelga la tarea o se aprueba a ciegas.filesystem.disabled(v2.1.216): apaga el aislamiento de ficheros y deja solo el de red. Útil cuando te importa a dónde conecta un comando, no qué escribe —pero es un intercambio de seguridad, no un atajo.- Riesgo de escalada: con los ficheros sin aislar y auto-aprobación, un
comando puede reescribir tu shell, tu
$PATHo tus settings y ampliarse el acceso. Solo para cargas de confianza. - Palanca de equipo:
filesystem.disabledno se activa desde el proyecto, solo desde settings de usuario, managed o--settings. Un repo clonado no puede bajarte la guardia.
Preguntas rápidas
¿Tengo que cambiar algo si ya uso el sandbox? No. Los dos ajustes están apagados por defecto y el comportamiento anterior —escritura confinada al directorio de trabajo y prompt ante cada dominio nuevo— sigue igual si no tocas nada.
¿filesystem.disabled desactiva el sandbox entero?
No. Apaga solo la capa de ficheros; el aislamiento de red sigue vigente y tus
comandos siguen limitados a los dominios que permitas. Por eso el propio ajuste
insiste en mantener el control de egress.
¿En qué se diferencia strictAllowlist del comportamiento por defecto?
Por defecto, la primera conexión a un host nuevo te pide permiso. Con
strictAllowlist, ese host —si no está en allowedDomains— se deniega sin
prompt. Cambias "pregúntame" por "bloquea y sigue".
¿Vais a dejar a Claude trabajar con autonomía en vuestro equipo? Decidir qué puede escribir y a dónde puede conectarse cuando nadie mira —y quién fija esa política, el proyecto o la organización— es justo el tipo de criterio que trabajamos en la formación en directo para equipos, sobre vuestro repo, vuestra configuración y vuestro modelo de amenazas real.