Anthropic publicó el 28 de agosto la versión 2.1.251 de Claude Code, y aunque el changelog la vende como una mezcla de correcciones y funciones nuevas, el motivo real para actualizar hoy está en la primera línea: las herramientas Read, Write y Edit seguían un enlace simbólico intercambiado dentro del directorio de trabajo después de haber validado los permisos. Es decir, el agente comprobaba que la ruta estaba autorizada y, en el instante que iba desde esa comprobación hasta el acceso real, alguien podía cambiar el destino del enlace. Con eso bastaba para leer o escribir fuera de las ubicaciones aprobadas.
La versión llega apenas tres días después de la 2.1.248, la que introdujo el modo --restricted, y en una semana en la que la seguridad de los agentes de programación ha sido la conversación dominante. No es casualidad que buena parte del release sean cierres de puertas.
Validar el permiso y acceder al fichero no eran el mismo momento
El patrón se conoce desde hace décadas y tiene nombre propio en seguridad: una condición de carrera entre la comprobación y el uso. Claude Code resolvía la ruta, decidía que el fichero caía dentro del directorio de trabajo permitido y procedía. Si entre esas dos operaciones el enlace simbólico pasaba a apuntar a otro sitio —a ~/.ssh, a un .env de otro proyecto, a cualquier cosa fuera del workspace—, la escritura o la lectura se ejecutaban sobre el nuevo destino con el permiso concedido para el antiguo. La corrección mueve la validación a un punto en el que ya no hay hueco entre comprobar y acceder.
Conviene entender el alcance real antes de alarmarse: explotar esto requiere que algo con capacidad de crear o modificar enlaces dentro de tu directorio de trabajo actúe en el momento exacto. En un repo local en el que solo trabajas tú, la ventana es teórica. En un directorio donde el propio agente descomprime archivos descargados, clona repositorios de terceros o procesa artefactos de un pipeline, deja de serlo. Y ese es precisamente el escenario que se ha vuelto habitual en flujos automatizados.
Grep y Glob ignoraban tus reglas deny
El segundo arreglo va en la misma dirección y afecta a más gente de la que parece. Las reglas deny que escribes en tu configuración para que el agente no toque determinadas rutas no se estaban aplicando cuando la ruta pasaba por un enlace simbólico. Si tienes un deny sobre una carpeta de credenciales y existe un symlink que lleva hasta ella desde dentro del proyecto, Grep y Glob la recorrían igualmente.
⚠️ Si dependías de las reglas deny como control real: hasta la 2.1.251 no cubrían rutas enlazadas. Merece la pena revisar si en alguno de tus proyectos hay enlaces simbólicos que crucen hacia carpetas que creías vetadas — los crea cualquier gestor de dependencias, cualquier monorepo y cualquier despliegue con directorios compartidos.
El release completa el bloque con tres cierres más: los comandos de un plugin ya no pueden referenciar rutas fuera de su propio directorio, las herramientas de Workflow no leen scriptPath fuera del ámbito permitido antes de validarlo, y las managed settings pueden ahora restringir el trazado beta detallado y el registro crudo del cuerpo de las peticiones a la API. Este último apartado incluye un detalle que interesa a cualquiera con observabilidad centralizada: un endpoint de trazado de menor alcance ya no puede esquivar el colector OTLP que haya fijado la organización.
Ya se puede vetar un cambio de modelo antes de que ocurra
La novedad funcional más útil son dos hooks nuevos: PreModelSwitch y PostModelSwitch. Permiten bloquear, confirmar o anotar un cambio de modelo dentro de una sesión. Hasta ahora, cuando la sesión saltaba de modelo —por límites de uso, por configuración o porque alguien lo pidió— eso pasaba sin que tu instrumentación se enterara, y con ello cambiaban silenciosamente el coste por token, la latencia y el comportamiento del agente a mitad de trabajo.
Para quien tiene agentes desatendidos, esto es control de gasto y de calidad al mismo tiempo. Un PreModelSwitch que rechace bajar de modelo en un pipeline de producción evita que una tarea crítica termine resuelta por un modelo más barato sin que nadie lo sepa; uno que simplemente lo anote te deja el registro para entender después por qué una ejecución concreta salió peor que el resto.
En la misma línea, los hooks SessionStart de reanudación reciben ahora dos datos que antes no tenían: la antigüedad de la sesión y el coste estimado de volver a cachear. Con eso se puede decidir con criterio si merece la pena retomar una sesión vieja o abrir una nueva, en vez de reanudar por costumbre y pagar la re-caché completa.
/cost por fin dice cuánto te cuesta perder la caché
El comando /cost añade una línea de caché de prompt por sesión con ratio de aciertos, fallos, tokens re-cacheados y contadores de arranques en caliente y en frío. Es información que hasta ahora solo se podía intuir mirando la factura a fin de mes. Si trabajas con contextos grandes —un CLAUDE.md extenso, muchas herramientas MCP declaradas, sesiones largas—, la caché es el factor que más mueve el gasto real, y ahora es medible sesión a sesión.
Se le suma una barra de límite de gasto en /usage para las cuentas gestionadas por gateway, y el streaming en vivo de las llamadas a herramientas de un subagente en primer plano hacia los clientes de Remote Control: ver qué está haciendo un subagente mientras lo hace, en lugar de esperar a que devuelva el resultado.
Las correcciones que desbloquean sesiones atascadas
Tres arreglos que probablemente hayas sufrido sin saber a qué culpar. El primero: conversaciones que se quedaban atascadas con el error text content blocks must be non-empty después de un turno en el que el modelo solo razonó y no emitió texto. El segundo: Opus 5 fallando cuando se deshabilitaba el thinking con el nivel de esfuerzo en xhigh o max —una combinación que la API rechaza desde el lanzamiento del modelo y que el CLI no estaba gestionando bien—. Y el tercero, para quien usa equipos de agentes: la respuesta final de un miembro no llegaba al líder, con lo que la orquestación se quedaba esperando algo que ya había ocurrido.
Qué hacer con esto si fijas versión
Si tienes Claude Code fijado a una versión concreta en un contenedor, en un runner de CI o dentro de un flujo de n8n —y deberías tenerlo—, este es un release para adelantar. No por los hooks ni por las métricas de caché, que son mejoras cómodas, sino porque las dos correcciones de rutas afectan a la garantía básica sobre la que descansa cualquier permiso que le hayas dado al agente: que dentro del directorio de trabajo signifique realmente dentro del directorio de trabajo.
- Actualiza primero los entornos desatendidos. Son los que ejecutan sin nadie mirando y los que más a menudo descomprimen o clonan contenido ajeno en su carpeta de trabajo.
- Revisa tus reglas
deny. Si las escribiste asumiendo que cubrían todo, comprueba ahora si hay enlaces simbólicos que las rodeaban. - Aprovecha para instrumentar el cambio de modelo. Un hook
PostModelSwitchque escriba una línea de log cuesta cinco minutos y te ahorra la próxima discusión sobre por qué una ejecución costó el triple. - Mira
/costen tu sesión más pesada. Si el ratio de aciertos de caché es bajo, ahí tienes el ahorro más grande disponible sin cambiar de modelo.
Tres releases en cinco días vuelven a dejar la misma lección que agosto lleva repitiendo: en Claude Code, el changelog no es lectura opcional. La diferencia entre una versión y la siguiente ya no está solo en lo que puedes hacer, sino en lo que el agente puede hacer sin que tú lo hayas autorizado.


















