La versión 2.1.260 de Claude Code corrige un grupo de fallos en el sistema de permisos que comparten una característica incómoda: ninguno de ellos avisaba. Una regla podía descartarse por inválida, otra podía tumbar en silencio todas las demás, y un comando de zsh podía auto-aprobarse escondiendo una sustitución dentro de una asignación de variable. En los tres casos, la sesión seguía funcionando con normalidad aparente.
Si tienes settings.json con reglas de permisos escritas a mano —y si trabajas con varios clientes, casi seguro que sí—, merece la pena leer esto con calma: puede que alguna de tus carpetas de solo lectura no lo fuera.
Una ruta con paréntesis y la regla se caía sola
El primer arreglo afecta a las reglas Edit, Write y Read cuya ruta contiene paréntesis. Hasta ahora se descartaban por inválidas, o el sandbox de Bash sencillamente las ignoraba. El resultado es el peor posible en materia de permisos: la regla estaba escrita, tú creías tenerla activa, y no protegía nada.
Y los paréntesis en rutas no son un caso raro ni rebuscado. Aparecen constantemente en copias de proyectos —esa carpeta cliente (backup) que todos tenemos—, en descargas duplicadas por el navegador con el sufijo (1), en rutas de Windows con Program Files (x86) y en cualquier estructura de carpetas creada por una persona en vez de por un script. Basta un paréntesis en el nombre de un directorio para que la protección que escribiste sobre él no existiera.
Un corchete sin cerrar y no podías editar nada
El segundo fallo va en la dirección contraria: en lugar de permitir de más, bloqueaba todo. Una sola regla con un patrón que no compila —el ejemplo típico es un [ sin cerrar— hacía que cualquier edición de archivo fallara con el mensaje Invalid regular expression.
El síntoma era especialmente confuso porque el error no señalaba a la regla culpable: aparecía al intentar editar un fichero cualquiera, aunque ese fichero no tuviera nada que ver con el patrón mal escrito. Una errata en la línea 40 de tu configuración rompía operaciones en toda la sesión, y el mensaje no daba ninguna pista sobre dónde mirar.
⚠️ Los dos fallos son la misma familia
Ambos nacen de tratar patrones de rutas como expresiones regulares sin una validación clara: en un caso la regla se descarta y crees estar protegido, en el otro la regla envenena todo el conjunto. La lección práctica es la misma: una configuración de permisos que no te dice qué reglas ha cargado y cuáles ha rechazado no es una configuración auditable.
Variables de zsh que colaban una sustitución de comandos
El tercer arreglo es el más interesante desde el punto de vista de seguridad. Las comprobaciones de Bash auto-aprobaban comandos de zsh que escondían una sustitución de comandos dentro de asignaciones a tres variables concretas: REPORTTIME, REPORTMEMORY y DIRSTACKSIZE.
La mecánica del problema es la clásica de este tipo de análisis. El verificador mira la forma del comando, ve una asignación a una variable de configuración del shell y la clasifica como inofensiva. Pero el valor asignado puede contener una sustitución, y esa sustitución se ejecuta igual. Es decir: una construcción que parece configuración termina siendo ejecución de código.
Vale la pena entender lo que esto implica más allá del parche concreto. Cualquier sistema que decida aprobar o denegar comandos analizando su texto compite contra la gramática entera del shell, que es enorme y llena de rincones. Este caso se ha cerrado; el patrón general —esconder ejecución donde el analizador espera datos— seguirá apareciendo. Por eso el modelo de permisos importa más que la lista de casos parcheados: si un flujo automatizado corre sin supervisión, la pregunta no es solo qué comandos apruebas, sino qué puede hacer el proceso si uno se cuela.
Marcha atrás en las reglas Read() sobre argumentos de Bash
La versión también revierte un cambio introducido en la 2.1.259: el que aplicaba las reglas Read() a los argumentos de los comandos de Bash. Sobre el papel sonaba coherente; en la práctica producía denegaciones absurdas.
El ejemplo que da el propio changelog lo resume bien: una regla Read(./**/build/**) hacía que npm run build quedara denegado en todos los modos. La palabra build aparecía en los argumentos del comando, la regla coincidía, y el comando se bloqueaba pese a que no estaba leyendo nada de esa carpeta. Cualquiera con una regla sobre dist, build o vendor se encontró con scripts de rutina fallando sin motivo aparente.
Revertirlo es lo correcto, y deja una enseñanza aplicable a tu propia configuración: una regla sobre rutas y una regla sobre comandos son cosas distintas, y mezclarlas genera tantos falsos positivos que la gente acaba desactivando los permisos por completo. Que es, exactamente, el peor desenlace posible.
Qué revisar en tu configuración esta tarde
Tres comprobaciones concretas, por orden de importancia. Primero, busca paréntesis en las rutas de tus reglas de Edit, Write y Read: si los hay, esas reglas no te han estado protegiendo y ahora sí lo harán, lo que puede cambiar el comportamiento de sesiones que dabas por buenas.
Segundo, si alguna vez viste un Invalid regular expression al editar y lo achacaste a un fallo pasajero, ya sabes de dónde venía: revisa tus patrones en busca de corchetes o llaves sin cerrar. Y tercero, si mantienes reglas de Read() que rozan nombres habituales de comandos o de scripts, vuelve a probar tus flujos automatizados después de actualizar, porque el comportamiento ha cambiado en las dos últimas versiones.
Ninguno de estos arreglos es vistoso y ninguno va a aparecer en un titular. Pero un sistema de permisos solo sirve si hace exactamente lo que dice el fichero de configuración, ni más ni menos. Esta versión acerca bastante Claude Code a ese punto, y ese es motivo suficiente para actualizar hoy si delegas trabajo con supervisión ligera.
