¿Claude Code no deja de pedir permiso? Soluciónalo sin --dangerously-skip-permissions
Aprobar npm test por cuadragésima vez es puro ruido. Claude Code tiene todo lo necesario para silenciar las solicitudes aburridas y conservar las peligrosas. Solo que está repartido entre tres archivos y seis modos.
RESPUESTA CORTA
Pon los comandos que siempre apruebas en permissions.allow (por ejemplo Bash(npm run *)), los que siempre deben detenerse en ask o deny, y elige un modo de permisos acorde a la tarea: acceptEdits para mucha edición, auto para el trabajo rutinario, plan para leer. Las reglas se evalúan en el orden deny → ask → allow, así que un deny nunca se puede anular. Usa /permissions para ver de dónde viene cada regla. Reserva --dangerously-skip-permissions para contenedores desechables.
Por qué Claude Code pregunta tan a menudo
En el modo predeterminado (que la CLI muestra como Manual), Claude Code pregunta la primera vez que usa cada herramienta, y vuelve a preguntar por cada comando de shell que no tenga permitido ejecutar. Esa solicitud es el momento en que puedes frenar un rm equivocado o un git push accidental, así que vale la pena conservarla. El problema es que también salta con los cientos de cosas inofensivas que hace un agente en una sesión.
Tres cosas deciden si ves una solicitud: las reglas de tus archivos de configuración, el modo de permisos en el que estás y las respuestas que diste antes con “Yes, and don’t ask again”. Para quitar el ruido hay que ajustar las tres.
A partir de Claude Code v2.1.283, las sesiones interactivas de terminal y de VS Code se inician en modo auto, en todos los planes y proveedores. En modo auto, un clasificador en segundo plano comprueba los comandos y las solicitudes de red frente a lo que pediste, en lugar de preguntarte por acciones rutinarias. Si aún ves una solicitud para todo, mira la barra de estado: “⏸ manual mode on” significa que estás en el modo predeterminado.
Reglas allow, ask y deny
Las reglas van bajo permissions en un archivo de configuración. Este ejemplo está tomado tal cual de la referencia de configuración de Anthropic:
allow: se ejecuta sin preguntar.ask: siempre pregunta, incluso en modos que de otro modo lo aprobarían.deny: nunca se ejecuta.
Lo importante es el orden: primero deny, luego ask, luego allow. Gana la primera coincidencia, y que una regla sea más específica no cambia el orden. Una regla allow no puede abrir una excepción en una regla deny, y si una herramienta está denegada en cualquier nivel, ningún otro nivel puede permitirla. Las reglas las aplica el propio Claude Code, no el modelo, así que escribir “nunca hagas push” en CLAUDE.md no equivale a una regla deny.
Cómo escribir una regla
| Regla | Con qué coincide |
|---|---|
Bash(npm run *) | npm run build, npm run test --watch, pero no npm install |
Bash(git log *) | Solo git log …. En cambio, Bash(git *) permite cualquier comando de git. |
Bash(ls:*) | Igual que Bash(ls *): :* es otra forma de escribir un comodín final |
Read(./.env) | Leer ese archivo. Las reglas Read y Edit usan patrones de gitignore |
Edit(//Users/alice/notes/**) | Una ruta absoluta. Una sola / inicial es relativa al archivo de configuración, así que las rutas absolutas necesitan // |
WebFetch(domain:example.com) | Solo example.com. Añade WebFetch(domain:*.example.com) para los subdominios |
mcp__github__* | Todas las herramientas del servidor MCP github. Las reglas con paréntesis después de mcp__ se ignoran |
En Windows, las reglas de PowerShell tienen la misma forma que las de Bash.
Qué archivo de configuración usar
| Ámbito | Archivo | Úsalo para |
|---|---|---|
| Usuario | ~/.claude/settings.json (Windows: %USERPROFILE%\.claude\settings.json) | Tus propias costumbres, en todos los proyectos |
| Proyecto, compartido | .claude/settings.json | Reglas que debe tener todo el equipo (súbelo al repositorio) |
| Proyecto, local | .claude/settings.local.json | Tus reglas personales para un repositorio (no se sube) |
| Administrado | managed-settings.json y otras fuentes administradas | Política de la empresa; nada puede anularla |
Precedencia, de mayor a menor: administrado, línea de comandos, proyecto local, proyecto compartido, usuario. Las claves de lista como permissions.allow se combinan entre archivos, no se reemplazan. Hay dos detalles en los que mucha gente tropieza:
- Los archivos de configuración son JSON estricto: un comentario
//o una coma final es un error de sintaxis, y se ignora el archivo entero. - Las reglas allow de un archivo de proyecto compartido solo se aplican después de que cada compañero confíe en la carpeta. Las reglas deny y ask se aplican de inmediato.
La mayoría de los cambios se aplican a la sesión en curso sin reiniciar, incluidos permissions y hooks. Para ver qué se cargó realmente, ejecuta /status (la línea Setting sources) o /permissions, que muestra cada regla y el archivo del que procede.
Qué guarda realmente “Yes, and don’t ask again”
Responder a una solicitud con “don’t ask again” escribe una regla por ti en .claude/settings.local.json, en la raíz del repositorio git. Cuánto dura depende de la herramienta:
| Herramienta | Se recuerda |
|---|---|
| Comandos de Bash | Permanentemente, por repositorio y comando |
| Ediciones de archivos | Hasta que termina la sesión |
| WebFetch | Permanentemente, por repositorio y dominio |
Así que si Claude vuelve a pedir permiso para editar archivos en cada sesión nueva, es intencionado: las aprobaciones de edición son por sesión. Usa el modo acceptEdits o una regla allow Edit(...). Y si un comando sigue preguntando incluso después de “don’t ask again”, busca una regla ask en un archivo de proyecto o administrado. Una regla allow en tu archivo local no tiene prioridad sobre ella.
Modos de permisos y cuándo usar cada uno
| Modo | Qué hace | Ideal para |
|---|---|---|
default (Manual) | Pregunta la primera vez que se usa cada herramienta | Repositorios desconocidos, trabajo arriesgado |
acceptEdits | Acepta las ediciones de archivos sin preguntar | Refactorizaciones largas que revisarás en git |
plan | Lee y planifica, no cambia nada | Explorar una base de código, diseñar un cambio |
auto | Sin solicitudes rutinarias; un clasificador revisa antes los comandos y las solicitudes de red | El trabajo diario |
dontAsk | No pregunta | Scripts y automatización |
bypassPermissions | Omite las solicitudes, incluidas las escrituras en .git y .claude | Solo contenedores o máquinas virtuales aislados |
Pulsa Shift+Tab para cambiar de modo. Desde auto, la primera pulsación lleva a default, y luego default → acceptEdits → plan. Define el modo inicial con permissions.defaultMode; ten en cuenta que auto y bypassPermissions solo surten efecto desde la configuración de usuario o administrada, no desde un archivo de proyecto.
Algunas cosas siempre preguntan, en todos los modos, incluido bypass: las reglas ask explícitas, las preguntas que Claude te hace y rm en rutas críticas, entre otras. Los administradores pueden desactivar los modos arriesgados estableciendo permissions.disableBypassPermissionsMode o permissions.disableAutoMode en "disable".
Sobre --dangerously-skip-permissions
--dangerously-skip-permissions equivale a --permission-mode bypassPermissions. La documentación de Anthropic es tajante: úsalo solo en entornos aislados, como contenedores, máquinas virtuales o dev containers sin acceso a internet. Se niega a ejecutarse como root en Linux y macOS, y en cuanto aceptas la advertencia establece skipDangerousModePermissionPrompt en tu configuración de usuario.
Si lo que de verdad quieres es “que deje de preguntar por cosas aburridas”, el modo auto más unas cuantas reglas allow te lo dan sin renunciar a las solicitudes que importan.
El sandbox: menos solicitudes con red de seguridad
Claude Code puede ejecutar comandos de shell en un sandbox. Está desactivado de forma predeterminada; actívalo con /sandbox o sandbox.enabled: true. Un modo del sandbox aprueba automáticamente los comandos aislados; el otro sigue preguntando. El sandbox solo cubre los comandos de shell: las herramientas de archivos, los servidores MCP y los hooks se ejecutan fuera de él.
Funciona en macOS, Linux y WSL2. En Windows nativo el sandbox no funciona, y los comandos se ejecutan sin aislamiento. Es otra razón para mantener allí una lista ask corta.
Una configuración que funciona
Este es un punto de partida razonable para un proyecto de JavaScript. Ajusta los comandos a tu stack:
- Empieza con una lista allow de comandos de solo lectura y de pruebas.
- Pon en
asktodo lo que salga de tu máquina (push, publish, deploy). - Deniega sin más el acceso a los secretos.
- Trabaja en auto o acceptEdits, y pasa al modo plan cuando estés explorando.
- Cada pocos días, abre
.claude/settings.local.jsony depura las reglas que añadió “don’t ask again”.
Cuando las solicitudes que quedan aparecen en el sitio equivocado
Después de ajustarlo, solo deberían preguntarte por cosas que merecen una decisión. El problema restante es dónde aparece la pregunta: en una pestaña de terminal detrás del navegador, donde el agente puede esperar veinte minutos hasta que te des cuenta.
Pet Island lleva esas preguntas a una pequeña isla en la parte superior de la pantalla. Cuando Claude Code necesita permiso, la solicitud aparece allí con el comando o el diff, y la permites, la deniegas o la permites siempre sin cambiar de ventana. Las preguntas y los planes de Claude Code también funcionan desde la isla, y si la isla está cerrada, Claude Code simplemente vuelve a preguntar en la terminal.
PREGUNTAS FRECUENTES
¿Cómo evito que Claude Code pida permiso para cada comando?
Añade los comandos de confianza a permissions.allow en ~/.claude/settings.json, por ejemplo "Bash(npm run *)", y usa el modo auto o acceptEdits. Deja los comandos arriesgados en permissions.ask para que sigan deteniéndose.
¿Por qué Claude Code vuelve a pedir permiso para editar archivos después de decirle don’t ask again?
Las aprobaciones de edición de archivos solo duran hasta que termina la sesión. Usa el modo acceptEdits o una regla allow Edit(...) si quieres que las ediciones queden aprobadas entre sesiones.
¿Puede una regla allow anular una regla deny?
No. Las reglas se evalúan en el orden deny, ask, allow, y gana la primera coincidencia. Una herramienta denegada en cualquier nivel no puede permitirse en otro.
¿Es seguro --dangerously-skip-permissions?
Anthropic lo recomienda solo en entornos aislados, como contenedores o máquinas virtuales sin acceso a internet. Además, omite las solicitudes para escribir en .git y .claude.
¿Dónde guarda la regla “Yes, and don’t ask again”?
En .claude/settings.local.json, en la raíz del repositorio git.
¿Funciona el sandbox de Claude Code en Windows?
No en Windows nativo; allí los comandos se ejecutan sin aislamiento. Funciona en macOS, Linux y WSL2.
Fuentes
Cada ajuste y comportamiento de esta página se comprobó con estas páginas el 26 de octubre de 2026. Los agentes cambian rápido; si algo ya no coincide, manda la página oficial.
- Documentación de Claude Code: Configure permissions
- Documentación de Claude Code: Permission modes
- Documentación de Claude Code: Settings
- Documentación de Claude Code: Settings reference
- Documentación de Claude Code: Sandboxing