Permisos en Claude Code: reglas allow, ask y deny

Hola, bienvenido. En la lección anterior creamos el .claude/settings.json de claude-tasks con una primera regla deny para el .env, y en esta lección vamos a completarlo con el resto de permisos del proyecto. Veremos cómo consultar las reglas con /permissions, cómo se escribe una regla y en qué orden las evalúa Claude Code. Con eso vamos a dejar que el circuito de calidad se ejecute sin preguntar, a obligar a Claude a pedirte permiso antes de aplicar Rector o de hacer push y a bloquear los comandos que destruyen datos. Para terminar, veremos hasta dónde llega de verdad una regla deny en Bash y por qué en nuestra configuración no hay ninguna regla Write(...).

¿Por qué merece la pena dedicarle una lección entera? Porque las reglas de permisos son lo que te permite trabajar con pocas interrupciones sin perder el control. Si cada composer qa te pide permiso, acabas aprobando por inercia, y el día que aparezca un comando peligroso lo aprobarás igual. Y si no hay nada que frene un migrate:fresh, tu base de datos de desarrollo depende de que Claude no se equivoque, y ya vimos en la lección de rewind que eso no se deshace volviendo a un checkpoint. El criterio que vamos a seguir en el curso es sencillo: deny compartido para lo que nunca debe pasar y allow conservador para lo que se repite y es seguro.

/permissions abre un diálogo con todas las reglas de permisos de la sesión y el archivo de configuración del que sale cada una. Desde ahí puedes verlas por ámbito, añadir y quitar reglas y gestionar los directorios de trabajo, y en la lección de auto mode ya usamos 2 de sus pestañas, Recently denied y Auto mode. Las reglas son de 3 tipos:

• allow: Claude Code usa la herramienta sin pedirte aprobación.
• ask: Claude Code te pide confirmación siempre que Claude intenta usarla.
• deny: Claude Code impide que Claude la use.

Puedes abrir el diálogo incluso mientras Claude está trabajando: desde la versión 2.1.234, los cambios se aplican a partir de la siguiente llamada a una herramienta de ese mismo turno. Y cuando añades una regla desde el diálogo, se guarda en el archivo de configuración que elijas, con sus mismas reglas de ámbito.

Para seguir esta lección necesitas claude-tasks con el .claude/settings.json de la lección anterior, los contenedores de Sail levantados y una sesión de Claude Code abierta en la raíz del proyecto. Ejecuta /permissions y busca las que ya tenemos: en la lista deny tienen que aparecer Read(./.env) y Read(./.env.*), las 2 con .claude/settings.json como origen.

En el curso vamos a escribir las reglas en settings.json, porque así quedan en el repositorio y se revisan como cualquier otro cambio, y vamos a usar /permissions para comprobar qué ha cargado Claude Code y de dónde. Recuerda lo que vimos en la lección de modos de permiso: quien aplica las reglas es Claude Code, y el modelo no puede saltárselas. Lo que escribas en un prompt o en CLAUDE.md influye en lo que Claude intenta hacer, pero lo que Claude Code le deja hacer lo deciden las reglas, el modo de permiso y los hooks.