Claude Code dangerously-skip-permissions: ¿cuándo es seguro?

--dangerously-skip-permissions desactiva las preguntas de permisos de Claude Code durante toda la sesión. Equivale a --permission-mode bypassPermissions, y la propia documentación de Anthropic dice que solo se use en contenedores o VMs donde Claude Code no pueda causar daños. Nosotros lo seguimos al pie de la letra: en el portátil de un desarrollador el agente trabaja con reglas allow, ask y deny más hooks, y el bypass total solo se ejecuta en un entorno aislado con sus propias cuentas.

La respuesta corta para un CTO: no prohíba el flag, decida dónde está permitido. Reglas para el portátil, hooks para lo que las reglas no ven, aislamiento para todo lo que funcione sin supervisión.

¿Qué desactiva realmente --dangerously-skip-permissions?

Claude Code tiene seis modos de permisos. El flag elige el último:

"Todo" tiene excepciones, y son importantes. Según la documentación de los modos de permisos, ningún modo aprueba automáticamente las herramientas que coinciden con una regla ask explícita, los borrados reconocidos con rm de rutas críticas ni las herramientas que necesitan a una persona, como AskUserQuestion. Los hooks también siguen ejecutándose. Lo que el bypass sí quita es la pregunta antes de escribir en rutas protegidas como .git y .claude, que todos los demás modos mantienen.

Así que bypass no significa "sin reglas". Significa "sin una persona en el bucle". La pregunta es si hay algo más en el bucle.

¿Cómo deciden las reglas allow, ask y deny?

Las reglas están en settings.json, en tres listas. Esta es una versión abreviada de nuestro Claude Code production starter público:

{
  "permissions": {
    "allow": ["Bash(pnpm check)", "Bash(pnpm test:*)", "Bash(bash scripts/gate.sh:*)"],
    "ask": ["Bash(git push:*)", "Bash(gh pr merge:*)", "Bash(vercel --prod:*)", "Bash(wrangler deploy:*)"],
    "deny": ["Read(**/.env)", "Read(**/*.pem)", "Bash(git push --force:*)", "Bash(git reset --hard:*)", "Bash(psql:*)"]
  }
}

La forma es la política. Allow para lo que el agente necesita para comprobar su propio trabajo. Ask para todo lo que sale de la máquina: un push, un merge, un despliegue. Deny para secretos, reescrituras del historial y acceso directo a la base de datos.

Claude Code evalúa primero deny, después ask y después allow, y gana la primera coincidencia. Un deny nunca se puede abrir con un allow más estrecho. Y vale también entre archivos: un deny en el repositorio se impone a un allow en la configuración personal de alguien. Por eso las reglas del equipo van en el .claude/settings.json del repositorio, y los atajos personales en ~/.claude/settings.json.

Esa frase es el motivo para pasar cada "nunca hagas X" de CLAUDE.md a una regla o a un hook.

¿Qué no puede ver una regla de permisos?

Una regla compara el texto del comando. Hay tres cosas que se le escapan:

• La rama. Bash(git push:*) no distingue git push origin feat/x de git push origin main. Si pregunta en cada push, la gente empieza a decir que sí sin leer.
• El acceso indirecto. La documentación lo dice claramente: las reglas deny de Read no cubren un script de Python o Node que abre el archivo por su cuenta, y un deny de Bash no coincide con el mismo programa dentro de sh -c.
• El contexto. Una regla no sabe quién ejecuta la sesión ni en qué tipo de repositorio está.

Ahí es donde un hook PreToolUse demuestra su valor. Recibe la llamada completa a la herramienta como JSON, puede ejecutar cualquier lógica, y exit 2 bloquea la llamada antes incluso de que se evalúen las reglas de permisos. El núcleo de nuestro push gate, abreviado:

CMD=$(jq -r '.tool_input.command // empty')
[[ "$CMD" != *"git push"* ]] && exit 0
BRANCH=$(git -C "${CLAUDE_PROJECT_DIR:-.}" branch --show-current 2>/dev/null)
if [[ "$CMD" =~ [[:space:]:](main|master)([[:space:]]|$) || "$BRANCH" == "main" ]]; then
  echo "Pushing to main is not allowed. Push a branch and open a PR." >&2
  exit 2
fi

El hook necesita su propio test, o puede quedarse mudo. Cómo pasa y cómo detectarlo lo contamos en Hooks de Claude Code que en silencio no hacen nada.

¿Cuándo es realmente seguro saltarse los permisos?

Cuando el propio entorno es el límite. Las ejecuciones sin supervisión usan --permission-mode bypassPermissions y --disallowedTools AskUserQuestion ExitPlanMode, porque no hay nadie para responder a una pregunta. Lo que lo hace aceptable no es el flag, sino lo que lo rodea. Para un agente de IA que funciona solo y trabaja issues, recomendamos esto:

Incluso en bypass, el merge lo hace una persona. El agente abre un pull request, la protección de rama exige una aprobación, y esa aprobación nunca es del agente.

El revisor de CI es el otro extremo. También funciona sin supervisión, pero recibe una lista explícita de herramientas en lugar de bypass:

claude_args: --allowed-tools "Read,Glob,Grep,Bash(git diff:*),Bash(git log:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Puede leer el diff y comentar. No puede editar, hacer push ni merge, así que no hay nada que saltarse.

¿Y el sandbox integrado?

Claude Code tiene un sandbox a nivel de sistema operativo que limita qué pueden leer, escribir y alcanzar en la red los comandos de shell, incluidos sus procesos hijos. Es la respuesta correcta al segundo punto ciego de arriba, porque no depende del texto del comando.

Antes de desplegar nada conviene conocer dos ajustes. permissions.disableBypassPermissionsMode: "disable" en las managed settings quita el bypass a todo el mundo. Un usuario también puede activarlo para sí mismo.

¿Cómo configurar los permisos de Claude Code para un equipo?

Revise lo que ya tienen sus repositorios:

El orden importa. Las reglas deny no cuestan nada y paran los peores casos desde el primer día. Después viene el hook. El aislamiento solo hace falta cuando algo se ejecuta sin que nadie lo vigile.

Cómo encajan estas reglas con CLAUDE.md y las convenciones del equipo lo cuenta Reglas para el código de IA en un equipo. Cómo el bucle sin supervisión lleva un issue hasta un pull request está en Harness engineering en la práctica.

¿Quiere agentes rápidos que aun así no puedan romper producción?

Configuramos reglas de permisos, hooks, aislamiento y CI directamente en los repositorios del equipo como parte de AI-native SDLC para equipos de desarrollo. La IA escribe la mayor parte de nuestro código. Un sénior revisa cada cambio y responde de lo que funciona en producción. Desde 2023 hemos entregado más de 15 proyectos en producción.

Le respondemos en un plazo de dos días laborables con algunas preguntas sobre su trabajo. Después acordamos qué hacemos primero.

Si prefiere hablar primero, reserve una llamada inicial de 15 minutos.

¿Hasta dónde llegaría hoy su agente si nadie respondiera a una sola pregunta?

Preguntas frecuentes

¿Qué hace --dangerously-skip-permissions en Claude Code?

Inicia la sesión en modo bypassPermissions, igual que --permission-mode bypassPermissions. Claude Code deja de preguntar antes de comandos, ediciones y descargas. Las reglas ask explícitas, algunos borrados críticos y las herramientas que necesitan a una persona siguen preguntando, y los hooks siguen ejecutándose.

¿Es seguro el modo YOLO de Claude Code?

Solo en un entorno aislado. Anthropic indica usar bypassPermissions solo en contenedores o VMs donde Claude Code no pueda causar daños. En el portátil de un desarrollador con credenciales reales, use reglas de permisos y hooks.

¿En qué orden se evalúan las reglas allow, ask y deny?

Primero deny, después ask y después allow. Gana la primera coincidencia en ese orden, así que una regla allow nunca puede abrir una excepción en una regla deny, y una regla ask pregunta aunque también coincida una regla allow más estrecha.

¿Dónde se guardan los permisos de Claude Code?

En archivos settings.json: managed settings para la organización, ~/.claude/settings.json para una persona, .claude/settings.json en el repositorio para el equipo y .claude/settings.local.json para ajustes locales. Las managed settings ganan, y un deny de cualquier nivel se impone a un allow de cualquier otro.

¿Cómo impido que los desarrolladores usen el modo bypass?

Configure permissions.disableBypassPermissionsMode como "disable", idealmente en las managed settings, donde nadie puede sobrescribirlo.