Claude Code --dangerously-skip-permissions: qué se salta el flag y qué sigue bloqueando

¿Qué hace de verdad claude --dangerously-skip-permissions?

Arranca Claude Code en modo bypassPermissions. La referencia de la CLI de Anthropic define el flag como «equivalente a --permission-mode bypassPermissions», y la página de modos de permisos dice que ese modo «desactiva las solicitudes de permiso y las comprobaciones de seguridad para que las llamadas a herramientas se ejecuten de inmediato, incluidas las escrituras en rutas protegidas». Ediciones de archivos, comandos de shell, peticiones web, herramientas MCP: todo corre con tu usuario y sin consultarte.

Lo de las «rutas protegidas» es justo lo que casi todos los tutoriales pasan por alto. En cualquier otro modo, una escritura en .git, .vscode, .claude, .mcp.json o en un perfil de shell como .zshrc se pregunta, pasa por un clasificador o se deniega. En modo bypass, la tabla de la documentación dice «Permitida». Y son archivos que otro programa ejecutará más tarde, el mecanismo que hay detrás de la mayoría de las fugas de sandbox divulgadas en 2026.

Esto es lo que el flag deja en pie y lo que no:

En una ejecución con -p no hay nadie para contestar, así que las llamadas que aún preguntarían se deniegan. La advertencia de Anthropic cabe en una línea: «bypassPermissions no ofrece ninguna protección frente a la prompt injection ni frente a acciones no deseadas».

¿Qué modos de permisos tiene Claude Code y cuál viene por defecto?

Tiene seis, y bypassPermissions nunca es el que viene de fábrica. En los planes Pro, Max y Team, una sesión de terminal nueva arranca en auto (desde la v2.1.228). Con un plan Enterprise, una clave de API de la Console, Bedrock, Foundry, claude -p o el Agent SDK arranca en default, que la interfaz muestra como Manual.

El modo de arranque sale, por este orden, del flag, de permissions.defaultMode en un archivo de settings y, a falta de ambos, del valor de fábrica. Hay un detalle que importa si clonas repositorios: la referencia de settings indica que auto y bypassPermissions «no surten efecto desde los settings de proyecto ni desde los locales», y añade: «Antes de la v2.1.257, bypassPermissions surtía efecto desde cualquier archivo». En versiones anteriores, un .claude/settings.json subido al repositorio podía elegir el modo bypass por ti, tras un diálogo de aviso que solo se mostraba una vez.

¿Se puede activar el modo bypass con Claude Code ya en marcha?

Solo si la sesión se lanzó con el bypass disponible. La documentación no deja margen: «No puedes entrar en bypassPermissions desde una sesión que iniciaste sin tenerlo activado». Para dejarte esa puerta abierta, arranca con --allow-dangerously-skip-permissions, que añade el modo al ciclo de Shift+Tab, detrás de plan. Un hook tampoco puede concederlo.

Ese flag tiene un efecto secundario. Con el bypass disponible en un terminal interactivo, los bloqueos del modo plan dejan de aplicarse: «A Claude se le sigue indicando que planifique sin editar, pero una edición de archivo o un comando de shell que intente durante la planificación se ejecuta sin preguntar». El modo plan pasa a ser una instrucción para el modelo y deja de ser un bloqueo impuesto por el cliente, salvo en las ejecuciones con -p, en el Agent SDK y en el panel de chat de VS Code.

¿Funciona --dangerously-skip-permissions en la extensión de VS Code?

Sí, pero detrás de un interruptor que viene apagado. La extensión solo muestra Bypass permissions en su indicador de modo después de que actives el ajuste «Allow dangerously skip permissions» (allowDangerouslySkipPermissions, false por defecto), cuya descripción reza: «Úsalo solo en sandboxes sin acceso a internet». Sin él, un bypassPermissions puesto como valor por defecto abre la conversación en Manual, y un repositorio no puede elegir el modo de arranque.

Lo que sí merece una prueba ahí es el sandbox. La issue #32814, abierta el 10 de marzo de 2026, denunciaba que la extensión lanzaba el binario sin --sandbox, de modo que sandbox.enabled: true no aplicaba ningún perfil Seatbelt. Se cerró automáticamente como duplicada cuatro días después y no hemos vuelto a probar las versiones actuales: pídele al agente que escriba fuera del workspace y mira qué ocurre.

¿Por qué --dangerously-skip-permissions falla como root o con sudo?

Porque Claude Code rechaza esa combinación en Linux y macOS. El error dice --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons, y la página de sandboxing da el motivo: «el acceso root, combinado con la ausencia de solicitudes de permiso, puede modificar cualquier archivo o servicio del sistema». La comprobación se omite «automáticamente dentro de un sandbox reconocido». Donde más se tropieza con esto es en Docker, porque allí los procesos corren como root por defecto, y el arreglo documentado es breve: «confirma que remoteUser apunta a una cuenta que no sea root».

¿Te sigue protegiendo el sandbox cuando omites los permisos?

A medias. El modo de permisos decide si una llamada a una herramienta se ejecuta; el sandbox integrado limita lo que un comando de Bash puede alcanzar una vez en marcha. Son independientes, de modo que en modo bypass los comandos de shell siguen confinados. El problema es que el sandbox solo cubre el shell. Lo dice la página comparativa de Anthropic: «Las herramientas de archivos integradas, los servidores MCP y los hooks siguen ejecutándose directamente en tu host».

Un ejemplo. Con el sandbox activado y los permisos omitidos, el sistema operativo frena un comando de shell que añada una línea a ~/.zshrc. A la herramienta Edit, cuando escribe en ese mismo archivo, no la frena nadie: «Read, Edit y Write usan directamente el sistema de permisos en lugar de pasar por el sandbox», y ese sistema lo acabas de apagar.

Queda además una vía de escape. Un comando que falla dentro del sandbox puede reintentarse con dangerouslyDisableSandbox, y el reintento «pasa por el flujo de permisos habitual», que en modo bypass ya no contiene ninguna pregunta. Pon sandbox.allowUnsandboxedCommands a false.

De ahí la regla de la documentación: las sesiones en bypass van «dentro de un contenedor, una máquina virtual o el sandbox runtime», donde las herramientas de archivos, los servidores MCP y los hooks también quedan dentro de la frontera. Codex traza la línea en otro sitio, con un único flag que quita aprobaciones y sandbox a la vez: lo contamos en nuestra guía de los flags de Codex.

El camino más corto es la Dev Container Feature de Anthropic, en .devcontainer/devcontainer.json y sin montar ningún secreto del host:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

npm install -g @devcontainers/cli
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . \
  claude -p "run the test suite and fix what fails" --dangerously-skip-permissions

Inicia sesión una vez dentro del contenedor, o pásale una ANTHROPIC_API_KEY de alcance limitado. Lo que consigues es un usuario sin root y una frontera de proceso, no una política de salida de red: el contenedor de referencia del repositorio anthropics/claude-code añade para eso un script de firewall que deniega por defecto. La página de dev containers avisa de que una sesión en bypass puede seguir exfiltrando «cualquier cosa accesible dentro del contenedor, incluidas las credenciales de Claude Code guardadas en ~/.claude». Monta el repositorio, nunca tu directorio personal.

¿Cómo hacer que Claude Code deje de pedir permiso a cada paso, sin el flag?

Con el modo automático (auto) o con reglas. El modo auto sustituye la pregunta por un modelo clasificador y ya es el valor por defecto en los planes Pro, Max y Team. En el resto, las reglas de permissions.allow aprueban de antemano los comandos que ejecutas a todas horas, acceptEdits quita las preguntas sobre las ediciones de archivos, y el modo auto-allow del sandbox ejecuta sin preguntar los comandos de shell confinados.

El argumento a favor de preguntar menos lo pone la propia Anthropic. Su artículo de ingeniería sobre el modo auto, del 25 de marzo de 2026, empieza así: «Los usuarios de Claude Code aprueban el 93 % de las solicitudes de permiso». Un control que dice que sí 93 veces de cada 100 tiene más de costumbre que de control. Lo que cuenta es qué ocupa su lugar, y para el flag la página de sandboxing responde: «Nada».

Un ~/.claude/settings.json que elimina la mayoría de las preguntas y conserva las peligrosas:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "disableBypassPermissionsMode": "disable",
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "ask": ["Bash(git push *)", "Bash(terraform *)"],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)"
    ]
  }
}

Las reglas se evalúan siempre en el mismo orden: primero deny, después ask, después allow. Para «permitirlo todo», el patrón documentado es un "Bash" a secas en allow más un hook PreToolUse que rechace los pocos comandos que no quieres ver nunca. La clave disableBypassPermissionsMode es la que buscan los administradores: colocada en los managed settings (la configuración gestionada) bloquea a todo el equipo, y a partir de ahí Claude Code «rechaza el flag --dangerously-skip-permissions».

Conviene conocer el límite de las reglas Bash(...). Comparan el texto del comando, y la página de permisos de Anthropic reconoce que una regla deny «cubre la invocación que Claude suele producir y no es una frontera de seguridad en torno al programa»: Bash(rm *) frena rm -rf build/, pero no /bin/rm -rf build/ ni bash -c 'rm -rf build/'.

¿Qué barreras de Claude Code siguen funcionando sin permisos?

Tres: las reglas deny, la comprobación de rutas críticas sobre rm y los hooks PreToolUse. La guía de hooks afirma que estos hooks «se disparan antes de cualquier comprobación del modo de permisos, en todos los modos», y que un hook que devuelve un deny «bloquea la herramienta incluso en modo bypassPermissions o con --dangerously-skip-permissions». De las tres, el hook es la única que ejecuta tu propia lógica.

Uno mínimo, registrado en ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "$HOME/.claude/hooks/guard.sh" }]
      }
    ]
  }
}

#!/bin/bash
# ~/.claude/hooks/guard.sh: exit 2 bloquea la llamada, stderr vuelve a Claude
CMD=$(jq -r '.tool_input.command')
if echo "$CMD" | grep -Eiq 'terraform[[:space:]]+destroy|drop[[:space:]]+(schema|database|table)|push[[:space:]].*--force'; then
  echo "Blocked: destructive command, ask the human to run it." >&2
  exit 2
fi
exit 0

Guárdalo en los settings de usuario o en los gestionados: en modo bypass, el directorio .claude del proyecto se puede escribir sin que nadie pregunte, así que el agente puede editar un hook que viva en el repositorio.

Y ahora los límites, porque esta guarda compara texto. La nota de investigación GuardFall de la Cloud Security Alliance, publicada el 11 de julio de 2026, burló con cinco clases de inyección de shell las guardas de comandos de diez de los once agentes de código open source que puso a prueba. Claude Code no estaba en la muestra, pero el razonamiento vale para cualquier comparador de texto: «Una guarda que inspecciona la cadena previa a la transformación y un shell que ejecuta la cadena posterior a la transformación están, en la práctica, evaluando dos comandos distintos».

Nuestra propia guarda de comandos se equivoca también en el otro sentido. En nuestro estudio controlado del 24 de agosto de 2026 comprobó 1.769 comandos de shell y rechazó 17: una captura real (un agente que iba a por una credencial almacenada), tres aplicaciones correctas de la política y 13 falsos positivos que le costaron un turno al agente cada uno, la mayoría por el token nc detectado dentro de un heredoc de Python. Una guarda de texto es un cable trampa para el caso habitual. La frontera que aguanta cuando la guarda falla es el contenedor.

¿De verdad Claude Code ha borrado una base de datos de producción?

Sí, y en el caso mejor documentado el flag no tuvo nada que ver. El 26 de febrero de 2026, Claude Code ejecutó terraform destroy contra la infraestructura de producción de DataTalks.Club y se llevó por delante la base de datos, 2,5 años de entregas de los cursos y todos los snapshots automáticos. Su fundador, Alexey Grigorev, publicó el post mortem el 6 de marzo; el soporte de AWS restauró los datos unas 24 horas después.

El agente avisó de lo que iba a hacer: «No puedo hacerlo. Voy a hacer un terraform destroy». Grigorev escribe que aquello «parecía lógico», así que «no detuve al agente». Su texto no menciona en ningún momento unos permisos omitidos: había una persona en el punto de control, y el comando pasó porque la justificación sonaba bien. Su resumen, que también recoge Tom's Hardware: «Traté plan, apply y destroy como algo que se podía delegar. Eso eliminó la última capa de seguridad». Para un equipo europeo, un borrado así sobre datos personales sería además una violación de la seguridad de los datos a efectos del RGPD, lo lance una persona o un agente.

93 %

de las solicitudes de permiso, aprobadas por los usuarios de Claude Code (Anthropic, 25 de marzo de 2026)

65

issues con rm -rf en el título en el tracker de Claude Code, 13 todavía abiertas (API de GitHub, 20 de septiembre de 2026)

17 %

de las acciones reales por exceso de celo que se le escapan al clasificador del modo auto, según el recuento de la propia Anthropic

Una búsqueda por título de rm -rf en el tracker de Claude Code devuelve 65 issues a 20 de septiembre de 2026, y una de ellas se titula, traducido, «Claude Code ejecutó rm -rf y borró todo el directorio personal». Son casos contados por usuarios, que no hemos verificado. El registro de incidentes de la propia Anthropic, en el mismo artículo sobre el modo auto, incluye «intentar migraciones contra una base de datos de producción».

Lo que habría ayudado, de más a menos eficaz: ninguna credencial de producción en la sesión y protección contra el borrado en la base de datos, que es lo que corrigió el propio Grigorev; una regla ask sobre Bash(terraform *); el hook de arriba; y el modo auto, cuya lista de bloqueos por defecto nombra terraform destroy.

Si nadie se salta los permisos, ¿se puede usar Claude Code en el trabajo sin riesgo?

Con menos riesgo, no sin él. Hay código que se ejecuta antes de que el sistema de permisos pueda opinar: la CVE-2025-59536 permitía que un proyecto ejecutara código antes de que se aceptara el diálogo de confianza del arranque (corregida en la 1.0.111), y la investigación GitSpawn de Manifold, del 1 de septiembre de 2026, logró que el comando core.fsmonitor de un repositorio se ejecutara «antes de que se aceptara el aviso de confianza del workspace». Además, los permisos solo deciden si una acción puede ejecutarse; nunca leen el código que escribe el agente.

Ese segundo límite es la razón de ser de este artículo. Todos los controles anteriores deciden qué puede ejecutar Claude Code, y ninguno mira lo que escribe. Una sesión en modo Manual, con cada pregunta leída por un ingeniero con los cinco sentidos puestos, puede acabar haciendo commit de un endpoint sin comprobación de autorización, porque un diff que compila no es un evento de permisos. Omitir los permisos quita el último punto de control humano sobre las acciones; mantenerlos no añade ninguno sobre el código. La página de seguridad de Anthropic te deja esa parte a ti: «Eres responsable de revisar el código y los comandos propuestos para comprobar que son seguros antes de aprobarlos».

Ahí es donde encaja un control agent-time. VibeDefend funciona como hooks dentro del mismo bucle: pone en el contexto del modelo las reglas que afectan a un archivo en el momento de la edición, devuelve al agente los hallazgos de SAST, SCA, secretos, IaC y CI/CD, y vigila los comandos dentro de los límites que acabamos de describir. En el estudio del 24 de agosto, el agente con la capa implementó de forma exacta 57 de los 64 detalles de regla evaluados (89 %), frente a 8 de 65 (12 %) sin ninguna herramienta. El mismo estudio recoge una tarea en la que la regla se sirvió trece veces y el agente desmontó igualmente sus propias salvaguardas: inyectar informa, no obliga. Tienes los detalles en ¿Claude Code sigue tu CLAUDE.md?, en la seguridad de los agentes de código con IA y en nuestra guía de seguridad de Claude Code.

Usa el flag a propósito, en un contenedor, con un usuario sin root, con reglas deny, un hook y algo que lea el diff, y tendrás un montaje defendible. En un portátil, pásate al modo auto, y hablemos de la parte que ningún modo de permisos cubre.

Preguntas frecuentes

¿Cuál es el comando para ejecutar Claude Code sin permisos?

claude --dangerously-skip-permissions, o su equivalente claude --permission-mode bypassPermissions, con -p "<prompt>" si la ejecución no es interactiva. Anthropic lo restringe a «entornos aislados como contenedores, máquinas virtuales o dev containers sin acceso a internet».

¿--dangerously-skip-permissions viene activado por defecto en Claude Code?

No. De fábrica, Claude Code arranca en modo auto en los planes Pro, Max y Team, y en Manual en todo lo demás. Para el bypass hace falta el flag, un defaultMode a nivel de usuario o un interruptor explícito en la extensión de VS Code y en la app de escritorio. Desde la v2.1.257, los settings de un repositorio ya no pueden seleccionarlo.

¿Puedo pasar a bypass permissions sin reiniciar Claude Code?

Solo si lanzaste la sesión con --allow-dangerously-skip-permissions, con el propio flag o con un defaultMode de usuario en bypassPermissions. Si no, el modo ni siquiera aparece en el ciclo de Shift+Tab.

¿Dónde se configura defaultMode en el settings.json de Claude Code?

En ~/.claude/settings.json, con "permissions": { "defaultMode": "acceptEdits" }. Valores admitidos: default (alias manual), acceptEdits, plan, auto, dontAsk y bypassPermissions. auto y bypassPermissions se ignoran cuando vienen de los settings de proyecto o locales, y la extensión de VS Code lee antes claudeCode.initialPermissionMode.

¿Cómo dar todos los permisos a Claude Code sin usar el flag?

Añade un "Bash" a secas en permissions.allow y registra un hook PreToolUse que rechace los comandos que no quieres nunca. Las reglas deny y ask siguen mandando. El modo auto es la alternativa de menos esfuerzo, aunque Anthropic advierte de que «no garantiza la seguridad».

¿Es seguro usar Claude Code en tu ordenador personal?

En modo Manual o auto, con reglas deny sobre los archivos .env, ~/.ssh y las carpetas de credenciales cloud, sí para el trabajo de cada día. Con los permisos omitidos directamente en el host, no: el agente actúa con tu usuario, con las claves SSH y las credenciales cloud a su alcance. Usa un contenedor.

¿Es seguro Claude Code para empresas?

Los controles existen: un managed-settings.json (en /etc/claude-code/ en Linux) con disableBypassPermissionsMode, allowManagedPermissionRulesOnly y allowManagedHooksOnly, más las claves del sandbox impuestas de forma centralizada. Gobiernan lo que el agente puede ejecutar. Ninguno revisa el código que produce: eso sigue siendo cosa tuya.