La versión 2.1.251 de Claude Code trae un bloque de cambios que apunta todo en la misma dirección: reducir lo que una configuración remota o de proyecto puede decidir sin que tú te enteres. Los ajustes servidos desde un servidor de configuración que rebajan el aislamiento del sandbox pasan a requerir aprobación explícita, ciertas cabeceras personalizadas también, y el settings.json de un repositorio pierde la capacidad de mover directorios sensibles. No es una función nueva; es un recorte de confianza.
Cuatro tipos de ajuste que ahora piden permiso
Los ajustes gestionados son los que una organización distribuye a las máquinas de su equipo desde un servidor. Es un mecanismo útil y legítimo —así se imponen políticas comunes—, pero también un canal por el que puede llegar configuración que cambia sustancialmente cómo se ejecuta el agente. A partir de esta versión, cuatro categorías de ajuste no se aplican hasta que las apruebas: los que terminan el TLS del sandbox, los que enrutan su tráfico por un proxy propio, los que inyectan credenciales y los que debilitan su aislamiento.
Merece la pena entender por qué son justo esos cuatro. Terminar el TLS del sandbox significa que alguien puede ver en claro el tráfico que sale de él. Enrutarlo por un proxy propio significa que ese tráfico pasa por una máquina que tú no controlas. Inyectar credenciales significa que el agente actúa con una identidad que no has configurado. Y debilitar el aislamiento significa, literalmente, que la caja deja de ser una caja.
El diálogo de aprobación, además, se ha vuelto más útil: ahora lista solo los ajustes que han cambiado desde la última vez que aprobaste, en lugar de volcarte la configuración entera. Es la diferencia entre leer tres líneas y aceptar a ciegas una pantalla completa, que es exactamente el fallo humano que este tipo de avisos suele provocar.
Un aviso que enseña la configuración entera se acepta sin leer; uno que enseña lo que ha cambiado, no.
Las cabeceras personalizadas entran en la misma lista
El mismo criterio se aplica a ANTHROPIC_CUSTOM_HEADERS cuando llega desde ajustes gestionados o de proyecto. Si esa variable fija una cabecera de credencial, de organización o inquilino, de enrutado o que altere el comportamiento de la API —Authorization o Host son los ejemplos que da la propia nota—, hace falta aprobarla antes de que surta efecto.
La lógica es la misma que en el caso anterior: una cabecera de ese tipo puede redirigir tus peticiones a otro sitio o hacerlas pasar por otra identidad. Que un fichero de un repositorio pudiera hacerlo en silencio era un agujero pequeño pero real, del tipo que solo se descubre cuando ya ha pasado algo.
En sentido contrario, y esto se agradece, la misma versión ha quitado del camino los avisos que no aportaban nada: los ajustes de tiempo de espera del cliente, el modo de arranque de los servidores MCP y las variables del vigilante de streaming ya no disparan el diálogo de aprobación. Un aviso que salta por todo acaba siendo un aviso que nadie lee.
Tu settings.json de proyecto ya no mueve directorios
El tercer cambio es el más silencioso y el que más gente va a notar sin saber por qué. El bloque env de un .claude/settings.json de proyecto ya no puede definir CLAUDE_CONFIG_DIR, CLAUDE_CODE_TMPDIR ni TMPDIR, TMP o TEMP. Si necesitas fijarlas, el sitio correcto pasa a ser tu shell, tus ajustes de usuario o los ajustes gestionados.
El motivo se entiende solo en cuanto piensas en qué controlan esas variables: dónde vive tu configuración y dónde se escriben los ficheros temporales. Un repositorio que puede reapuntar cualquiera de las dos cosas puede, en la práctica, decidir desde dónde lee y hacia dónde escribe la herramienta. Y un settings.json viaja en el repositorio, lo que significa que basta con clonar el proyecto equivocado.
Hay un cuarto ajuste en la misma línea, más específico: los ajustes de proyecto tampoco pueden ya activar el trazado beta detallado ni el registro del cuerpo crudo de las peticiones a la API. Es decir, un repositorio ajeno no puede encender el modo que vuelca lo que envías al modelo.
⚠️ Si clonas repositorios de clientes, esto te afecta
El patrón común de todos estos cambios es el mismo: un fichero que viene dentro de un repositorio dejaba de ser solo configuración de proyecto y podía alterar cómo se ejecuta la herramienta en tu máquina. Si trabajas con código de terceros, revisa qué trae el .claude/ de los proyectos que abres, igual que ya miras un Makefile antes de ejecutarlo.
El sandbox deja de fiarse de sus propios ficheros
Completa el bloque un cambio de fontanería que no aparece en ningún resumen: la forma en que se crean y se leen los ficheros de salida de los comandos de Bash cuando se ejecutan dentro del sandbox. Ahora un comando aislado no puede redirigirlos ni sustituirlos. Traducido: el canal por el que el sandbox devuelve el resultado de un comando ya no es manipulable por el propio comando.
Junto al fallo de symlinks corregido en esta misma versión —que el portal ya cubrió— dibuja una intención clara: cerrar las vías por las que algo ejecutado dentro del recinto podía influir en lo que ocurre fuera. No son funciones que vendan releases, pero son las que deciden si puedes dejar una sesión trabajando sola.
Para el lector que trabaja por su cuenta, la implicación práctica es corta: actualiza y no toques nada, porque los valores por defecto ya son los correctos. Para quien administra equipos, hay una tarea real: si distribuyes ajustes gestionados que caen en alguna de las cuatro categorías, tus desarrolladores van a ver un diálogo de aprobación la próxima vez que arranquen. Conviene avisarles de qué es y por qué aparece, porque un aviso inesperado que nadie ha explicado se acepta rápido y sin leer, que es justo lo contrario de lo que este cambio pretende.
