Permisos de Claude Code: reglas allow, deny y ask, explicadas
Un recorrido fotograma a fotograma de cómo Claude Code pide permiso: las tres opciones del prompt, las reglas allow que se guardan en settings.local.json, el orden de evaluación con deny primero, los modos de permiso y las recetas que hacen que el día a día y la CI pregunten menos — con la documentación oficial cubriendo cada hueco que deja el vídeo.
Permisos de Claude Code en 60 segundos
- Claude Code pregunta antes de Bash, Edit, WebFetch y Write; Read, Glob, Grep y LS corren sin preguntar.
- «Yes, and don't ask again» guarda una regla como Bash(git add:*) en .claude/settings.local.json — tu libreta de reglas personal, excluida de git, para ese repo.
- Las reglas se evalúan deny → ask → allow: un deny de cualquier archivo de settings gana, y ninguna regla allow puede abrirle una excepción.
- Los modos dosifican la confianza: acceptEdits (alt+m) para trabajo con muchas ediciones, plan para reconocimiento de solo lectura, bypassPermissions para la CI vía --permission-mode — y los valores defaultMode auto y bypassPermissions solo surten efecto desde settings user o managed.
Claude Code Tutorial #4 - Tools & Permissions
Canal:The Net Ninja4:55
Permission Modes Head to Head
Canal:ttywood6:20
Permissions — Claude Code documentation
Docs:code.claude.com
Settings files — Claude Code documentation
Docs:code.claude.com
Cada fotograma procede de la grabación de Net Ninja, una captura de pantalla limpia sin cámara ni overlays. El episodio de ttywood que compara los modos de permiso cara a cara sirvió de contraste para las secciones de modos y recetas, pero no aportó fotogramas — los suyos llevan subtítulos incrustados. La sintaxis de reglas, el orden de evaluación, el comportamiento de los modos y la precedencia de archivos de settings están verificados contra las dos páginas de documentación oficial.
Vídeos © The Net Ninja y ttywood, solo enlazados. Documentación © Anthropic. Las capturas de pantalla se referencian en esta guía como material de comentario.
Configurar los permisos de Claude Code, paso a paso
Qué pide Claude Code antes de actuar
- 1
Mira qué herramientas disparan un prompt de permiso
Claude Code elige sus propias herramientas — Read para abrir archivos, Edit para cambiarlos, Bash para comandos de shell. La documentación de settings de Anthropic le dedica a cada una una columna Permission Required: Bash, Edit, WebFetch y Write se detienen y preguntan, mientras que Read, Glob, Grep y LS corren sin más. Tú nunca escribes nombres de herramientas; la cuestión es saber de antemano qué acciones se detendrán por ti.
La documentación de settings de Claude Code lista cada herramienta integrada con su veredicto en Permission Required.Ver en 1:05 - 2
Pide una edición y mira cómo lee primero
En el vídeo la petición es deliberadamente pequeña: añadir una variable --highlight amarillo pastel a src/app/globals.css. Claude Code lee el archivo primero — Read nunca pide permiso — y solo se detiene cuando va a cambiarlo. Esa separación es todo el modelo de permisos en miniatura: mirar es gratis, tocar pregunta.
La petición de la variable highlight escrita en la entrada de Claude Code en VS Code.Ver en 1:45 - 3
Lee las tres opciones antes de responder
Cada prompt de edición ofrece tres respuestas. 1. Yes aprueba solo esta edición. 2. Yes, and don't ask again this session aprueba el resto de ediciones de la sesión (alt+m en la build mostrada). 3. No, and tell Claude what to do differently (esc) rechaza el cambio y te deja tomar el mando. La opción 3 no es un fracaso — es así corriges el rumbo antes de que aterrice el código.
El prompt de edición de globals.css con las tres opciones de permiso a la vista.Ver en 2:17
Di sí una vez: guarda una regla allow
- 4
Espera un prompt por edición, no por tarea
La aprobación no se traslada al siguiente cambio. La demo necesitó tres pulsaciones de Yes para tres ediciones separadas del mismo archivo, y el cambio siguiente volvió a preguntar. El sí-a-cada-paso funciona, pero escala mal pasado el encargo de dos líneas — exactamente por eso existen las reglas allow y los modos.
Una segunda edición de globals.css que pregunta de nuevo justo después de aprobar la primera.Ver en 2:32 - 5
Los comandos de Bash preguntan por separado
Los comandos de shell tienen su propia puerta. Cuando la demo pide a Claude hacer un commit, Bash(git add src/app/globals.css) queda en estado Waiting hasta que respondes. Un sí para un comando no es un sí para el siguiente — el git commit que viene después pregunta por su cuenta.
El comando git add esperando aprobación mientras la salida git anterior se desplaza encima.Ver en 3:16 - 6
Deja que «don't ask again» escriba la regla por ti
Elegir Yes, and don't ask again con los comandos git add hace dos cosas a la vez: desbloquea el comando actual y guarda una regla. El archivo que crea es .claude/settings.local.json en la raíz del repo, con un objeto permissions y un array allow — aquí "Bash(git add:*)" — más arrays deny y ask vacíos. Todos los git add futuros de este proyecto ya corren sin preguntar.
settings.local.json creado bajo .claude con la regla allow Bash(git add:*) guardada.Ver en 3:40 - 7
Edita las reglas a mano cuando el diálogo no puede
El array allow es JSON plano, así que puedes añadir reglas tú mismo. Usa una cadena exacta para un solo comando — Bash(npm run test) — y un :* final para todo lo que empiece igual — Bash(npm run test:*). La documentación confirma que :* es el atajo del comodín final. Mantén el archivo personal: Claude Code excluye settings.local.json de git automáticamente, y el vídeo dice lo mismo — es para tu flujo de trabajo, no para el repo.
La regla guardada seleccionada dentro de permissions.allow mientras se edita el archivo a mano.Ver en 4:22
Sube y baja la delegación con los modos
- 8
Cambia a accept edits para las rachas de ediciones
alt+m (shift+tab va rotando los modos en las builds actuales) pone la insignia de la sesión en accept edits on. Las ediciones de archivos aterrizan ya sin prompts, y la documentación añade que los comandos de sistema de archivos habituales — mkdir, touch, mv, cp — también se autoaceptan. La gracia dura lo que la sesión: sesión nueva, vuelta a los prompts por edición, hasta que vuelvas a activarlo.
La insignia accept edits on mientras los comandos git permitidos terminan el commit.Ver en 4:35 - 9
Conoce toda la escalera de modos antes de subirla
Los modos fijan la postura por defecto de una sesión. default pregunta en el primer uso de cada herramienta; plan es exploración de solo lectura que no edita nada; acceptEdits autoacepta las ediciones de archivos; dontAsk deniega automáticamente todo lo que preguntaría; auto aprueba llamadas a herramientas con comprobaciones de seguridad en segundo plano; bypassPermissions se salta los prompts salvo para el pequeño grupo de acciones que ningún modo puede autoaprobar. Elige uno por sesión con --permission-mode, o hazlo permanente con permissions.defaultMode.
- 10
Pon defaultMode en el archivo correcto
La documentación de settings es tajante: los valores defaultMode auto y bypassPermissions no surten efecto desde settings de proyecto o locales — ponlos en user (~/.claude/settings.json) o managed, o pasa --permission-mode para una sola sesión. La precedencia va managed → CLI --settings → .claude/settings.local.json → .claude/settings.json → user, y un deny en cualquier nivel vence a cada allow por debajo.
Recetas para copiar y pegar en proyectos reales
- 11
Receta: permite los tests, veda la destrucción
En el .claude/settings.json compartido por el equipo, permite el bucle de tests con "Bash(npm run test:*)" y acota las partes peligrosas con "Bash(rm -rf *)" y "Read(./.env)" para que los secretos nunca se puedan leer. La investigación web fija la misma pauta: "WebFetch(domain:example.com)" para un dominio, "WebFetch(domain:*.example.com)" para todo un subdominio. Como deny se evalúa primero, ninguna regla allow puede abrirle una excepción.
- 12
Receta: salta los prompts en CI sin peligro
Las ejecuciones no interactivas exigen una postura deliberada, no accidental: pasa --permission-mode bypassPermissions al job de CI o fija defaultMode en settings user o managed — un archivo de proyecto no puede concederlo. Para blindar la barrera, pon permissions.disableBypassPermissionsMode en "disable" en managed settings y audita cualquier máquina con /permissions, que lista cada regla activa y el archivo del que viene.
deny → ask → allow: cómo se evalúan de verdad las reglas
La documentación de permisos lo dice sin ambajes: las reglas se evalúan en orden — deny, luego ask, luego allow — la primera coincidencia decide, y la especificidad de una regla nunca cambia ese orden. Una regla allow no puede abrir una excepción en una deny, por precisa que sea.
El deny también es global entre archivos. Si los settings user permiten un comando y los de proyecto lo deniegan, gana el deny, porque las reglas deny de cualquier ámbito se evalúan antes que las allow — y un deny de managed settings no lo anula ni un flag de línea de comandos. Denegar el nombre desnudo de una herramienta como "Bash" va aún más lejos: la documentación dice que retira la herramienta del contexto de Claude por completo.
La consecuencia práctica: publica tus reglas de seguridad — deny rm, deny lectura de .env, deny force-pushes — en el .claude/settings.json del proyecto que viaja con el repo, y trata las listas allow como comodidades que se apilan encima. Las listas allow se combinan entre ámbitos en vez de sobrescribirse, así que tu settings.local.json personal puede añadir permisos sin debilitar los vetos de nadie.
Tres recetas que querrás copiar
Cada receta nombra el archivo donde va. Una constante vale para todas: el deny gana en todas partes, siempre.
Tests libres, con rm y .env bajo llave
En .claude/settings.json: "permissions.allow": ["Bash(npm run test:*)"] (cámbialo por "Bash(npx vitest:*)" o "Bash(uv run pytest:*)" según tu stack), "permissions.deny": ["Bash(rm -rf *)", "Read(./.env)"]. Los tests y sus callbacks corren solos; los borrados destructivos y las lecturas de secretos se bloquean antes de que la evaluación llegue a tu lista allow.
Fija la investigación en los dominios de confianza
Para trabajo con mucha documentación: "WebFetch(domain:developer.mozilla.org)" y "WebFetch(domain:claude.com)" en allow, o "WebFetch(domain:*.example.com)" para cubrir un subdominio entero. Denegar la herramienta desnuda "WebFetch" apaga por completo la lectura web — útil para ejecuciones reproducibles que deben quedarse en el contexto local.
CI headless sin que se desmande
Haz que el job de CI pase --permission-mode bypassPermissions, o fija "permissions.defaultMode": "bypassPermissions" en settings user o managed — los settings de proyecto y locales no pueden concederlo. Para vetar el modo de raíz, "permissions.disableBypassPermissionsMode": "disable" en managed settings deja fuera todo repo y todo flag. Aun así, bypassPermissions sigue bloqueando la lista corta de acciones que ningún modo puede autoaprobar.
¿Tu regla no funciona? Revisa estas cuatro cosas
La mayoría de avisos «mi allow se ignora» se reducen a en qué archivo cayó la regla y qué archivo gana.
- 1Regla correcta, archivo equivocado. Las aprobaciones de sesión caen en .claude/settings.local.json; las reglas de equipo van en .claude/settings.json; las de toda la máquina en ~/.claude/settings.json. Ejecuta /permissions — lista cada regla activa y el archivo de settings del que procede.
- 2Un archivo superior la deniega. Los valores se heredan hacia abajo, pero un deny de cualquier nivel se evalúa antes que los allow, así que un allow de nivel user nunca rescata un deny de proyecto — y los managed settings ganan a todo, incluidos los flags de línea de comandos.
- 3La regla allow espera confianza. Las reglas deny y ask se aplican al momento, pero las allow de un archivo de proyecto commiteado solo entran en vigor tras dar confianza a la carpeta del workspace — una barrera deliberada para repos clonados.
- 4Modo en el archivo equivocado. Los valores defaultMode auto y bypassPermissions se ignoran desde settings de proyecto y locales (la documentación señala que cambió en v2.1.257 — antes, bypassPermissions surtía efecto desde cualquier archivo). Muévelos a user o managed settings, o usa --permission-mode para una sola sesión.