Claude Code --dangerously-skip-permissions no es un atajo normal para ahorrar clics. En el contrato actual de permisos equivale a --permission-mode bypassPermissions: Claude Code continúa sin la capa habitual de confirmaciones. Eso afecta a escrituras de archivos, comandos de shell, llamadas de red y acciones de herramientas con efectos secundarios. La regla práctica verificada el 7 de mayo de 2026 es sencilla: no lo conviertas en el modo por defecto de tu portátil, de un repositorio con secretos reales, ni de una terminal capaz de desplegar, borrar datos, cambiar infraestructura o tocar facturación.
Antes de copiar el comando, separa la molestia real. Si solo te cansan las confirmaciones de ediciones previsibles, empieza con acceptEdits. Si tienes trabajo largo, repetible y de bajo riesgo, revisa si Auto mode está disponible para tu versión, plan, modelo, provider y superficie. Si el repositorio es nuevo, el impacto no está claro o estás diagnosticando un fallo, usa el modo normal o plan. El bypass completo solo tiene sentido cuando el entorno ya es desechable: sin credenciales de producción, sin red interna, sin autoridad de despliegue y con un diff fácil de revisar y revertir.
Decisión rápida:
- Código desconocido o impacto incierto:
defaultoplan. - Fatiga por ediciones rutinarias:
acceptEdits. - Trabajo largo y repetible dentro del repositorio: Auto mode si aplica.
- Producción, secretos, base de datos, nube, despliegue o facturación: no usar bypass.
- Entorno aislado y desechable, sin autoridad real: solo entonces evaluar
bypassPermissions.
Respuesta rápida: qué desactiva realmente
La documentación actual de modos de permisos de Claude Code trata --dangerously-skip-permissions como equivalente a --permission-mode bypassPermissions. No mejora el razonamiento del modelo ni hace que la tarea sea más fiable. Cambia la superficie de control: acciones que antes se detenían para pedir aprobación ahora pueden seguir sin esa pausa.
Esa pausa no es solo fricción. Es donde ves el archivo exacto que se va a escribir, el comando que se va a ejecutar, si la sesión intenta salir a la red o si la tarea se ha desplazado a una parte más peligrosa del sistema. Muchas incidencias nacen de un pequeño cambio de alcance: una corrección de documentación que termina ejecutando un instalador, una prueba que modifica artefactos generados, una revisión de configuración que lee .env, o una instrucción de repositorio que convierte el trabajo en despliegue.
Elige el modo antes que la sintaxis:
| Situación | Modo inicial | Motivo |
|---|---|---|
| Repositorio nuevo, bug incierto, alcance poco claro | default o plan | Necesitas visibilidad antes de actuar |
| Muchas confirmaciones de ediciones normales | acceptEdits | Reduce ediciones, mantiene comandos visibles |
| Trabajo repetible y de bajo riesgo | Auto mode | Menos interrupciones sin quitar todo el control |
| Entorno desechable sin autoridad real | bypassPermissions | La frontera de seguridad es el entorno |
| Producción, secretos, nube, DB, facturación, despliegue | No usar | El radio de daño es demasiado alto |
Esta tabla debe aparecer antes del comando porque el comando es fácil. Lo difícil es demostrar que una acción equivocada no puede alcanzar nada valioso.
Escalera de permisos: sube solo lo necesario
Es mejor pensar en una escalera de riesgo que en un interruptor para quitar preguntas. El modo normal sigue siendo el punto de partida para trabajo desconocido. Detiene acciones con efectos secundarios para que revises destino, comando, archivo e intención. En diagnósticos, migraciones, dependencias, configuración, autenticación y cambios de release, esa pausa aporta información.
plan sirve cuando el riesgo principal no es una orden concreta, sino el enfoque. Si estás cambiando permisos, moviendo datos, tocando build, refactorizando varios módulos o trabajando cerca de pagos, primero necesitas una estrategia visible. Un mal plan se detecta más barato antes de editar que después de acumular cambios parciales.
acceptEdits resuelve mucha fatiga real. Permite que Claude Code escriba cambios esperados en archivos, pero conserva la revisión de comandos, red y herramientas externas. Para documentación, pruebas, tipos y refactors pequeños suele ser suficiente y es un contrato de confianza mucho más estrecho que el bypass total.
Auto mode es la zona intermedia. Existe porque muchos usuarios aprobaban una gran parte de los prompts, pero el bypass completo exponía demasiado. No lo describas como algo disponible para todos los planes y superficies de forma permanente. Depende de versión de Claude Code, plan, modelo, provider y entorno de uso.
dontAsk y bypassPermissions exigen frenar. No son una medalla de usuario avanzado. Son contratos más amplios. Cuanto más se eliminan los prompts, más trabajo deben hacer el sandbox, la red, la ausencia de secretos, las reglas de comandos y el plan de reversión.
Líneas rojas: tareas donde no debes usar bypass
Si una tarea puede dañar un sistema compartido, filtrar un secreto, cambiar dinero o crear estado irreversible, --dangerously-skip-permissions no es el atajo correcto. No es un problema exclusivo de Claude Code. Cualquier agente con shell, sistema de archivos y red puede cometer un error caro si interpreta mal la tarea, sigue una instrucción maliciosa o ejecuta un script con más alcance del previsto.
Evita bypass completo en estas categorías:
- despliegues de producción, rollbacks, promotion de release o reinicios;
- migraciones de base de datos, consultas destructivas o cambios masivos;
- Terraform, IAM, recursos cloud, permisos de repositorio, billing;
- rotación de secretos, búsqueda de tokens, limpieza de
.env, debugging de credenciales; - ejecución de código descargado, instaladores desconocidos,
curl | bash, binarios no revisados; - force push, push directo a ramas protegidas o borrado masivo;
- cualquier entorno con credenciales reales, cloud CLI, SSH o sesión de navegador administrativa.
Las categorías bloqueadas alrededor de Auto mode muestran la misma lógica: downloaded code, production deploys, migrations, exfiltration, cloud-storage mass deletion, IAM, repository grants, shared infrastructure, irreversible destruction, force push y direct push to main requieren control humano o límites duros. Un circuit breaker de última instancia no es una estrategia de seguridad.
En equipos conviene convertir esas líneas rojas en reglas ejecutables. Un alias o wrapper puede negarse a arrancar en la rama principal, con diff sucio sin checkpoint, con variables de secretos visibles, con scripts de deploy/migrate/publish, o con perfiles cloud activos. Eso no vuelve seguro al bypass; impide iniciarlo donde no corresponde.
Checklist de aislamiento antes de saltar prompts
La documentación de sandboxing de Claude Code insiste en dos ejes: sistema de archivos y red. Una rama nueva no es un sandbox. Docker tampoco lo es si monta el home, tiene egress amplio, conserva credenciales reales o puede llamar a servicios internos y herramientas cloud.
Checklist mínimo:
| Frontera | Requisito mínimo | Verificación |
|---|---|---|
| Archivos | worktree desechable, repo estrecho, diff limpio | pwd, git status, ignored/generated paths |
| Red | sin egress amplio o con salida limitada | sin prod, staging, APIs internas, object storage |
| Secretos | sin tokens reales ni .env vivo | env vars, credential files, keychain, shell history |
| Comandos | sin deploy, billing, IAM, migration ni scripts destructivos | package scripts, Makefile, CI helpers, cloud CLI |
| Reversión | cambios visibles y reversibles | checkpoint commit, tests, logs, rollback |
| Regla de parada | una frontera no se puede demostrar | volver a default, plan, acceptEdits o Auto |
Preparación básica:
bashgit status --short git worktree add ../tmp-claude-bypass-work -b claude-bypass-test cd ../tmp-claude-bypass-work
Luego retira autoridad antes de buscar velocidad:
bashenv | grep -E 'TOKEN|KEY|SECRET|AWS|GCP|AZURE|ANTHROPIC|OPENAI' ls -la | grep -E '\.env|credentials|secrets' git diff --stat
Si esas comprobaciones muestran credenciales reales, un workspace amplio o acciones irreversibles, la respuesta correcta no es "lo vigilo con cuidado". La respuesta es estrechar el entorno hasta que el error sea barato.
Superficies: CLI, IDE, Remote Control, cloud y CI no son iguales
No asumas que todas las superficies de Claude Code exponen los mismos controles. El CLI local es el lugar más claro para razonar sobre modos porque ahí ves flags, cambio de modo y /permissions. IDE, Remote Control, cloud sessions y ejecuciones no interactivas añaden límites propios.
| Superficie | Qué esperar | Criterio sobre bypass |
|---|---|---|
| CLI local | modos y flags documentados más visibles | aun así elegir el menor riesgo |
| VS Code / IDE | advanced modes pueden depender de settings | útil para ediciones acotadas y diff review |
| Remote Control | supervisión y aprobación remota | no es ejecución desatendida |
| cloud sessions | los docs actuales no exponen Ask permissions, Auto o Bypass | no tratarlo como fallo del CLI local |
| CI | suele tener secretos y autoridad de release | preferir scripts estrechos, dry run, approvals |
| secretos/admin | la autoridad cambia todo el riesgo | no usar bypass |
Remote Control sirve para aprobar, rechazar o redirigir desde otro dispositivo. Auto mode sirve para reducir interrupciones en parte del trabajo repetible. El bypass completo es otra cosa: una decisión local para un entorno ya aislado. Mezclar esas superficies crea una sensación falsa de supervisión.
Comandos después de la barrera de seguridad
Solo después de decidir la frontera, usa la sintaxis:
bashclaude --permission-mode bypassPermissions
El alias visible en muchos scripts es:
bashclaude --dangerously-skip-permissions
La primera forma encaja mejor con la terminología actual de permission modes. La segunda aparece en scripts antiguos, issues y notas de compañeros. En runbooks de equipo conviene mapear ambas para que nadie las trate como contratos de seguridad distintos.
Comprobaciones útiles:
bashclaude --version claude --help
Dentro de la sesión:
text/permissions
Si cambias de modo durante el trabajo, deja constancia en la nota o commit message. El bypass más peligroso es el invisible: un diff donde nadie sabe cuándo la sesión dejó de pedir aprobación.
También hay detalles con fecha. Los docs revisados el 7 de mayo de 2026 describían cambios alrededor de protected paths en v2.1.126 y un circuit breaker para borrados de root/home. No conviertas eso en garantía permanente. La práctica robusta es no dar a la sesión un sistema de archivos peligroso desde el inicio.
Troubleshooting: sigue preguntando o no aparece el modo
Primero revisa la superficie. Cloud sessions, Remote Control, IDE y CLI local no se comportan igual. Que una opción no aparezca en una superficie no demuestra que el contrato del CLI haya cambiado.
Segundo, separa Auto mode de bypass. Auto es una alternativa de menos prompts con condiciones de versión, plan, modelo, provider y superficie. Si no aparece, puede ser eligibility, no un bug de permisos.
Tercero, no confundas circuit breaker con prompts normales. Si una acción extrema todavía se detiene, eso no hace seguro al bypass; solo indica que queda una frontera de emergencia.
Cuarto, mira las políticas de organización. Managed settings, allowlists, denylists, dev containers y auditoría pueden hacer que el comportamiento local sea más estrecho que un ejemplo público. No lo resuelvas subiendo permisos. Ajusta el flujo a la política.
Por último, si Claude Code insiste en acciones riesgosas, baja de modo. Usa plan para resetear alcance, acceptEdits para fatiga de edición o Auto si el trabajo encaja. El bypass completo no debe ser la forma de vencer una herramienta prudente.
Preguntas frecuentes
¿Es lo mismo que bypassPermissions?
Sí. Los docs actuales de permission modes vinculan --dangerously-skip-permissions con --permission-mode bypassPermissions. Escríbelo en tus instrucciones internas para que el flag antiguo no parezca un modo oculto.
¿Docker lo vuelve seguro?
Solo si está realmente aislado. Un contenedor con mounts del host, red amplia, credenciales reales o herramientas de producción sigue siendo peligroso.
Solo quiero aprobar menos ediciones, ¿lo uso?
Normalmente no. Empieza con acceptEdits. Reduce confirmaciones de edición y conserva el juicio sobre comandos y red. Si el trabajo encaja, Auto mode puede ser mejor.
¿Protege contra prompt injection?
No. bypassPermissions no ofrece protección contra prompt injection ni acciones no previstas. Si archivos externos, dependencias o instrucciones del repositorio pueden influir en la sesión, el hueco de revisión aumenta.
¿Puedo usarlo en CI?
No como default general. CI suele conectar secretos, despliegue, publicación de paquetes e infraestructura compartida. Para trabajo desatendido, diseña scripts estrechos, dry runs, approvals explícitos y sandbox sin autoridad de publicar o borrar.
¿Cuál es la regla más segura?
Usa el modo menos permisivo que resuelve el cuello de botella real. acceptEdits para fatiga de edición, Auto mode para trabajo largo y elegible, bypass completo solo en aislamiento desechable sin producción, secretos, billing ni sistemas compartidos.