Permisos de Claude Code: una lista de partida

Las reglas de permisos deciden qué puede hacer Claude Code sin preguntar. Son cortas, viven en un archivo JSON y las aplica el programa, no el modelo.

Las tres listas

• allow: se ejecuta sin preguntar.
• ask: pregunta siempre, aunque otra regla de allow también encaje.
• deny: bloqueado.

Se comprueban en este orden: deny, luego ask, luego allow, y gana la primera que encaja. Dos consecuencias: un deny amplio no lo deshace un allow más concreto, y un deny en cualquier archivo de ajustes gana a un allow en otro.

Dónde van las reglas

• ~/.claude/settings.json: tuyo, para todos los proyectos.
• .claude/settings.json: del proyecto; se puede subir a git para que lo comparta el equipo.
• .claude/settings.local.json: tuyo, solo para este proyecto. No es para subirlo.

Escribe /permissions en una sesión para ver todas las reglas y de qué archivo viene cada una.

Una lista de partida

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

Léela línea a línea. Compilar y probar corren solos. Los commits corren solos. Un push siempre se para y pregunta. El archivo .env y la carpeta secrets/ quedan fuera del alcance de las herramientas de archivos de Claude.

Cómo funcionan los patrones

• Un nombre solo, como Bash, encaja con todos los usos de esa herramienta. Con paréntesis, encaja con un tipo de uso.
• En Bash, * encaja con cualquier texto, espacios incluidos. Ponlo después del subcomando: Bash(git log *) permite solo git log, mientras que Bash(git *) permite todos los comandos de git.
• Una regla sin * encaja solo con ese comando exacto.
• Las reglas de archivos llevan rutas: Read(./.env), Read(./secrets/**). Las descargas web llevan un dominio: WebFetch(domain:example.com).

Los modos son otro interruptor

Las reglas dicen qué está permitido. El modo fija cuánto pregunta. Los nombres son default (pregunta la primera vez que usa cada herramienta), acceptEdits (acepta ediciones de archivos en la carpeta de trabajo), plan (explora y lee, no edita tus archivos), auto, dontAsk (rechaza todo lo que preguntaría) y bypassPermissions. Fija un modo de partida con defaultMode. Deja bypassPermissions para contenedores y máquinas virtuales desechables, donde un error no llega a nada que te importe.

Lo que las reglas no hacen

• Una línea en CLAUDE.md no es una regla. Orienta lo que Claude intenta. Solo una regla en los ajustes cambia lo que está permitido.
• Un deny de Bash no es hermético. No encaja con el mismo programa llamado por otra vía, por ejemplo git -C . push frente a una regla para git push, o un comando envuelto en sh -c. Trátalas como un cinturón de seguridad. Para lo que no debe pasar nunca, añade un sandbox o mantén la credencial fuera de su alcance.
• Un archivo .claudeignore no hace nada. Pasa sus entradas a reglas Read en deny.
• La sintaxis cambia entre versiones. Una regla que Claude Code no puede usar se salta con un aviso al arrancar, y claude doctor muestra tus ajustes ya resueltos; compruébalo tras editar.

Comprueba que funciona

1. Añade las reglas primero a .claude/settings.local.json de un proyecto de pruebas.
2. Ejecuta /permissions y confirma que cada regla aparece.
3. Pide algo que cada regla debería parar y algo que debería permitir. Las dos cosas deben comportarse así.

Esta página sigue la documentación de permisos de Anthropic tal como la leemos en octubre de 2026. Esa página manda, y no tenemos relación con Anthropic. La escribimos a partir de la documentación y no hemos probado la lista de partida desde el punto de vista de seguridad.

Si quieres una segunda mirada a tu CLAUDE.md y a tus ajustes, el Tune-Up Kit es una lista de comprobación para eso (la ficha está en inglés).

Mira también: Claude Code en GitHub Actions.