Claude Code acaba de añadir algo que llevaba tiempo faltando: una pestaña de Auto Mode dentro de /permissions que enseña qué reglas está aplicando el clasificador cuando decide ejecutar un comando sin preguntar. La misma actualización incorpora un aviso cuando una regla con comodines — el ejemplo del changelog es Bash(git * main) — puede acabar coincidiendo con más comandos de los que su autor tenía en mente, y reduce el tiempo de arranque del CLI al dejar de bloquear el primer frame esperando al sandbox y al registro de servidores MCP.
Sobre el papel es un cambio menor de interfaz. En la práctica toca el punto donde se decide qué se ejecuta en tu máquina sin que tú lo apruebes, que es exactamente el sitio donde la opacidad sale cara.
Un clasificador que decidía sin enseñar sus cartas
El modo automático existe para eliminar la fricción del flujo de trabajo. Sin él, cada comando de lectura, cada grep, cada ls y cada test lanzado desde el agente se convierten en una petición de permiso, y una sesión larga acaba siendo una sucesión de confirmaciones que nadie lee con atención después de la vigésima. Ese cansancio de aprobación es un problema de seguridad en sí mismo: quien aprueba en piloto automático no está revisando nada.
La solución fue delegar parte de esa decisión en un clasificador que distingue entre lo inocuo y lo que merece una pausa. Funciona bien, pero introducía un problema nuevo: el usuario veía el resultado y no el criterio. Cuando un comando se ejecutaba solo, no había forma cómoda de saber si había pasado por una regla escrita por ti, por una configuración heredada del proyecto o por el juicio del propio clasificador.
Eso genera un tipo de duda particularmente difícil de resolver, porque sin visibilidad solo quedan dos reacciones posibles y ninguna es buena: desactivar el modo automático entero y volver a la fatiga de confirmaciones, o asumir que funciona y dejar de pensar en ello. La pestaña nueva convierte una decisión implícita en algo consultable, que es la condición previa para poder corregirla.
Una regla de permisos que no puedes leer no es un permiso: es una suposición.
Por qué git * main abarca más de lo que parece
El segundo cambio es el que más conviene entender, porque afecta a reglas que probablemente ya tengas escritas. Cuando alguien define un permiso como Bash(git * main), la intención suele ser evidente: permitir operaciones normales contra la rama principal, del estilo de git push origin main o git merge main.
El problema es que git acepta opciones globales antes del subcomando. Construcciones como git -c algo=valor push origin main o git --git-dir=/otra/ruta push origin main son sintaxis perfectamente válida, y encajan en el patrón igual de bien que la forma que tenías en mente. El comodín no distingue entre el hueco que dejaste para el subcomando y un hueco que alguien rellena con configuración arbitraria.
La consecuencia práctica es que una regla pensada para autorizar una familia de operaciones puede terminar autorizando una forma de reconfigurar git sobre la marcha. No hace falta imaginar un atacante para que esto importe: basta con un agente que resuelve un problema de credenciales o de rutas metiendo una opción global, y que pasa el filtro porque el patrón sigue coincidiendo. El aviso nuevo no bloquea nada, pero señala qué reglas tienen esa forma ambigua para que puedas cerrarlas.
💡 Cómo cerrar una regla demasiado abierta
En lugar de un comodín en medio, escribe reglas que fijen el subcomando desde el principio: una para git push origin main, otra para git merge main, y así con lo que uses de verdad. Son más reglas y más aburridas de mantener, pero cada una autoriza exactamente una operación. El comodín conviene reservarlo para el final del patrón, no para el hueco donde va el verbo.
Qué revisar en tus permisos esta semana
La actualización es una buena excusa para hacer algo que casi nadie hace nunca: leer las reglas de permisos que tienes acumuladas. En un uso intensivo, esas reglas se escriben en caliente, en mitad de una tarea, para desbloquear algo concreto — y ahí se quedan meses. Merece la pena mirar tres cosas.
- Reglas con comodín en medio del patrón. Son las que el nuevo aviso señala. Cualquier
Bash(algo * otracosa)merece una lectura de si el hueco central puede rellenarse con algo distinto de lo previsto. - Reglas que ya no usas. Los permisos escritos para un proyecto que terminó siguen activos si viven en tu configuración de usuario. Un permiso caducado es superficie de riesgo sin ninguna contrapartida.
- Dónde vive cada regla. No es lo mismo un permiso en la configuración del proyecto — que se aplica a ese repositorio y viaja con él — que uno global que acompaña a todas tus sesiones, incluidas las que abres en repositorios de cliente.
Esa última distinción es la más relevante para quien trabaja por proyectos. Una regla cómoda escrita durante un experimento personal se aplica igual cuando abres el repositorio de un cliente, y ahí el margen de error es otro. Los permisos amplios pertenecen a los repositorios donde el peor caso es rehacer tu propio trabajo, no a aquellos donde el peor caso implica una llamada incómoda.
El arranque también deja de esperar al sandbox
El tercer cambio del release es de rendimiento y menos vistoso, pero se nota a diario. Hasta ahora, la inicialización del sandbox y el registro de los servidores MCP bloqueaban el primer frame de la interfaz: abrías Claude Code y esperabas sin nada en pantalla mientras esas dos piezas terminaban de montarse. Ahora la interfaz aparece antes y el resto se resuelve por detrás.
El detalle importa más de lo que sugiere el ahorro en segundos, porque afecta sobre todo a quien tiene varios servidores MCP configurados: cada uno añade su parte al arranque, y quien ha construido un entorno con conexiones a bases de datos, repositorios o herramientas propias es precisamente quien más veces al día abre el CLI. Cuando una herramienta tarda en abrirse, la reacción natural es dejarla abierta en sesiones eternas — con el contexto que eso arrastra — en lugar de abrir una sesión limpia por tarea, que suele ser la mejor práctica.
Sumados, los tres cambios apuntan a la misma dirección: menos comportamiento invisible. Auto Mode enseña sus reglas, los comodines ambiguos se señalan y el arranque deja de esperar en silencio. Ninguno añade una capacidad nueva, pero todos reducen la distancia entre lo que crees que hace la herramienta y lo que hace realmente, que es justo la distancia donde se cuelan los incidentes.
