Tabla de contenidos
- 1. ¿Qué es el "bypass" en primer lugar?
- 2. La razón real: el sistema de permisos de 2 capas
- 3. Capa 1: IU de permisos de herramientas (controlable con bypass)
- 4. Capa 2: Juicio de seguridad de la IA (no controlable con bypass)
- 5. Patrones de operaciones en los que Claude pregunta por su cuenta
- 6. ¿Por qué dos capas? La filosofía de diseño
- 7. Formas prácticas de reducir las confirmaciones
- 8. Resumen
- FAQ
Has configurado el flag --dangerously-skip-permissions en Claude Code, pero Claude sigue enviando un mensaje en el chat preguntando "¿Puedo ejecutar esta operación?" ¿Te resulta familiar?
El primer instinto es pensar "el bypass no está funcionando", pero eso no es lo que ocurre. El sistema de permisos de Claude Code tiene dos capas independientes, y el modo bypass solo controla una de ellas.
Este artículo cubre todo: desde "qué es el bypass" hasta la diferencia entre ambas capas, los tipos de operaciones en los que Claude pregunta por su cuenta y formas prácticas de reducir las confirmaciones al automatizar tareas.
1. ¿Qué es el "bypass" en primer lugar?
En software, "bypass" significa saltarse el flujo normal de confirmación o aprobación para continuar directamente. Piensa en el botón "comprar ahora" de una tienda online que salta la pantalla de revisión: eso es un bypass del flujo de confirmación.
En el modo Manual de Claude Code (valor de configuración default), aparece un diálogo de confirmación antes de editar cualquier archivo o ejecutar cualquier comando de shell. Eso sí, desde Claude Code v2.1.283 las sesiones de terminal y de VS Code empiezan por defecto en el modo Auto en todos los planes y proveedores, donde un clasificador revisa la mayoría de las acciones en lugar de preguntarte (en versiones anteriores, solo en los planes Pro, Max y Team; si un administrador ha desactivado el modo auto o el modelo no lo admite, se empieza en Manual).
# Modo Manual: confirmación antes de cada acción
$ claude --permission-mode default
> Please fix index.js
[Claude Code] May I edit index.js? → Yes / NoEl modo de bypass de permisos omite (bypasea) ese flujo de confirmación.
# Modo bypass: casi sin diálogos de confirmación
$ claude --dangerously-skip-permissions
# or
$ claude --permission-mode bypassPermissionsNótese que el flag incluye la palabra dangerously. Anthropic posiciona este modo como destinado únicamente a contenedores o entornos aislados — no se recomienda para el desarrollo local habitual. Para un análisis completo de los riesgos del modo bypass, consulta Modo bypass de Claude Code: riesgos y uso seguro.
Si los diálogos de confirmación siguen apareciendo a menudo, comprueba primero si de verdad estás en modo bypass. Mientras está activo, la barra de estado de la terminal muestra ⏵⏵ bypass permissions on. Si no aparece, hay dos causas habituales.
- Lo configuraste en los ajustes del proyecto: poner
bypassPermissionscomodefaultModeen.claude/settings.jsono.claude/settings.local.jsonno tiene efecto, y la sesión empieza en modo Manual (v2.1.257 y posteriores). Ponlo en tus ajustes de usuario (~/.claude/settings.json) o en los ajustes administrados, o pasa el flag al iniciar - Intentaste cambiar a mitad de sesión: el bypass solo se puede elegir en una sesión que lo tenía habilitado al iniciarse. En una sesión iniciada sin él, pulsar Shift+Tab nunca llega al bypass
Además, la primera vez que inicias una sesión interactiva en bypass, Claude Code muestra una única advertencia que te pide aceptar la responsabilidad de las acciones realizadas sin comprobación de permisos (tu aceptación se guarda en los ajustes de usuario).
2. La razón real: el sistema de permisos de 2 capas
La respuesta a "¿por qué sigue apareciendo la confirmación incluso con bypass activado?" es que el sistema de permisos de Claude Code está construido sobre dos capas independientes.
Sistema de permisos de Claude Code: arquitectura de 2 capas
El modo bypass solo puede desactivar la "Capa 1" (y aun en ella quedan algunas confirmaciones)
--dangerously-skip-permissions desactiva casi toda la Capa 1 (quedan las reglas ask, el borrado de rutas críticas y poco más). La Capa 2 no puede omitirse.
Confundir estas dos capas es la causa raíz del malentendido "el bypass no funciona". Veamos cada una en detalle.
3. Capa 1: IU de permisos de herramientas (controlable con bypass)
La primera capa es el diálogo de confirmación que aparece antes de ejecutar una herramienta: la IU interactiva que aparece cuando Claude Code está a punto de editar un archivo o ejecutar un comando de shell.
| Herramienta | Ejemplo de diálogo de confirmación |
|---|---|
| Edición de archivo | "¿Puedo modificar index.js?" |
| Ejecución de Bash | "¿Puedo ejecutar npm install?" |
| Acceso web | "¿Puedo acceder a https://...?" |
Esta es exactamente la capa que el modo bypass desactiva. Con --dangerously-skip-permissions, diálogos como estos casi nunca aparecen y Claude puede ejecutar herramientas libremente. Incluso la escritura en rutas protegidas como .git y .claude pasa sin confirmación en modo bypass. En este sentido, el modo bypass funciona correctamente.
Confirmaciones que aparecen incluso en modo bypass (excepciones de la Capa 1)
La clave está en el "casi". La documentación oficial indica que Claude Code no aprueba automáticamente lo siguiente en ningún modo, bypass incluido (fuente: la página oficial de Claude Code "Choose a permission mode", a 22 de septiembre de 2026).
- Acciones que coinciden con una regla ask: lo que hayas puesto en
permissions.asken tus ajustes (por ejemplo,Bash(git push *)) pide confirmación cada vez, incluso en modo bypass - Herramientas que necesitan tu intervención:
AskUserQuestion, con la que Claude te hace una pregunta con opciones; las herramientas MCP marcadas como que requieren interacción del usuario; y las herramientas de conectores que tu organización configuró en ask rmyrmdirdirigidos a rutas críticas: borrados que apuntan a la raíz del sistema de archivos y sus directorios de primer nivel (como/usr), a tu directorio personal o a tu directorio de trabajo y sus directorios padre. La documentación lo llama un cortacircuitos (circuit breaker) contra los errores del modelo, y ninguna regla allow ni ningún hook puede aprobarlo. Sin embargo, en la aplicación Desktop y en VS Code, desde la v2.1.309 estos comandos se deniegan de inmediato sin preguntar, y la denegación devuelve pistas para reescribir el comando, de modo que no se bloqueen las sesiones en las que no hay nadie presente (historial de cambios oficial)- Otros: las salvaguardas de mensajería entre sesiones y los comandos Bash que leen fuera de tus directorios de trabajo mientras
permissions.blockReadsOutsideWorkingDirectoriesestá activado
Las reglas también cuentan. Las reglas deny siguen aplicándose en modo bypass y bloquean las acciones que coinciden. Las reglas allow, en cambio, no tienen efecto en modo bypass (todo pasa ya). En las ejecuciones no interactivas con -p, estas pocas confirmaciones se deniegan en lugar de esperar una respuesta.
Nota: existen 6 modos de permisos
Claude Code tiene seis modos de permisos: Manual (default), Aceptar ediciones (acceptEdits), Plan (plan), Auto (auto) y Omitir permisos (bypassPermissions), más dontAsk, que nunca aparece en el ciclo de Shift+Tab y deniega automáticamente todo lo que pediría confirmación (pensado para CI). El bypass (bypassPermissions) es el menos restrictivo. Para más detalles sobre cada modo, consulta el artículo sobre los modos de permisos.
4. Capa 2: Juicio de seguridad de la IA (no controlable con bypass)
La segunda capa es el juicio de seguridad autónomo de Claude. Está completamente separado de la IU de confirmación de herramientas.
Cuando Claude determina que una operación puede tener consecuencias significativas, envía un mensaje de confirmación en el chat como texto plano. No es un mecanismo de ejecución de herramientas, sino el comportamiento conversacional de Claude como IA.
--dangerously-skip-permissions omite los diálogos de la IU de la Capa 1, pero no tiene ningún efecto sobre este juicio de la IA de la Capa 2, porque la Capa 2 es un principio de comportamiento integrado en el propio modelo de Claude.
Error común
"Activé el modo bypass pero Claude se detuvo → el bypass no funciona"
→ Más exactamente, distínguelo por la forma en que Claude se detuvo. Si Claude preguntó con texto en el chat: "La IU de la Capa 1 está desactivada, pero el juicio de la IA de la Capa 2 está solicitando confirmación." Si apareció en la terminal un diálogo que pide permiso, es una de las confirmaciones de la Capa 1 que el bypass conserva, como una regla ask o el borrado de una ruta crítica. En ambos casos, el bypass funciona correctamente (si no es ninguno de los dos y las confirmaciones continúan, puede que ni siquiera hayas iniciado en modo bypass).
Eso sí, la Capa 2 no es una garantía de seguridad. Que Claude pregunte o no es una decisión del momento, y no necesariamente se detendrá antes de una acción peligrosa. La documentación oficial también advierte de que el modo bypass no ofrece ninguna protección contra la inyección de prompts ni contra acciones no deseadas. Lo que nunca deba ejecutarse, bloquéalo con una regla deny.
5. Patrones de operaciones en los que Claude pregunta por su cuenta
Por Tipo de Operación: ¿Qué Capa Gestiona la Confirmación?
Capa 1 (UI de permisos) vs Capa 2 (Juicio de IA)
Los criterios internos de Claude para "debo confirmar esto" se agrupan en tres categorías principales.
① Irreversibilidad
Las operaciones que no se pueden deshacer hacen que Claude sea más cauteloso. La eliminación permanente de archivos, git push --force y DROP TABLE son ejemplos claros. Dado que los errores son difíciles de recuperar, Claude hace una pausa y pregunta.
② Alcance del impacto
Las acciones que afectan a entornos de producción, grandes cantidades de archivos u otros usuarios generan verificaciones más frecuentes. Modificar un solo archivo local rara vez provoca una pregunta; cambiar el esquema de una base de datos de producción casi siempre lo hace.
③ Riesgo de seguridad
Las operaciones que envían archivos .env, tokens de autenticación o claves de API a sistemas externos son marcadas como alto riesgo de seguridad por Claude, que preguntará antes de continuar.
Algunos borrados, sin embargo, no quedan en manos del juicio de Claude: rm y rmdir dirigidos a rutas críticas como la raíz, tu directorio personal o el propio directorio de trabajo quedan frenados por el propio Claude Code (Capa 1), incluso en modo bypass (la CLI muestra una confirmación, mientras que la aplicación Desktop y VS Code los deniegan directamente desde la v2.1.309). Es una de las pocas confirmaciones que el bypass no elimina.
Estos juicios están integrados en el modelo de IA de Claude y no se pueden desactivar completamente mediante configuración. Para más información sobre cómo los agentes de IA están diseñados para operar de forma segura, consulta ¿Qué es un agente de IA?.
6. ¿Por qué dos capas? La filosofía de diseño
¿Por qué dos capas? — La filosofía de diseño
Entenderlo con la analogía del albañil
Aquí hay una analogía que hace intuitivo el diseño de dos capas.
Imagina que contratas a un albañil para renovar una habitación y le das una llave de repuesto, diciéndole "puedes hacer lo que necesites." Eso equivale a conceder permisos de herramienta.
Pero cuando el albañil está a punto de derribar una pared y pregunta "¿Esta pared es de carga? ¿Estás seguro de que quieres que la quite?", está preguntando basándose en su propio juicio profesional, no porque haya perdido la llave.
Darle la llave no impide que el albañil piense. Su juicio profesional y conciencia de seguridad operan de forma independiente a la llave.
Claude funciona de la misma manera. El modo bypass le da a Claude "la llave para usar herramientas", pero no detiene el juicio de la IA de Claude. De hecho, que Claude haga una pausa antes de operaciones de alto riesgo es una función de seguridad intencional, no un fallo.
7. Formas prácticas de reducir las confirmaciones
En pipelines de CI/CD y otros escenarios de automatización, puede ser necesario que Claude complete las tareas sin detenerse. Aquí están los enfoques más efectivos.
Enfoque 1: usar CLAUDE.md para proporcionar contexto
Crea un archivo CLAUDE.md en la raíz de tu proyecto explicando el entorno y las restricciones. Cuando Claude entiende "este es un entorno seguro y aislado", la frecuencia de confirmaciones se reduce significativamente.
# About This Environment
This repository runs inside a CI/CD pipeline test environment.
- Runtime: fully isolated Docker container
- Production impact: none
- All changes are rollback-safe
Please proceed without asking for extra confirmation.Enfoque 2: dar instrucciones pequeñas y específicas
Las instrucciones vagas aumentan la incertidumbre de Claude y provocan más confirmaciones.
| Tipo de instrucción | Ejemplo | Frecuencia de confirmación |
|---|---|---|
| Vaga | "Limpia este proyecto" | Alta |
| Específica | "Elimina los imports sin usar en src/" | Baja |
| Vaga | "Despliégalo" | Alta |
| Específica | "Ejecuta npm run deploy:staging en el entorno de staging" | Baja |
Enfoque 3: probar primero el modo auto
Antes de recurrir al modo bypass completo, prueba el modo auto. Ejecuta un clasificador de seguridad en segundo plano mientras aprueba automáticamente la mayoría de las operaciones, y además anima a Claude a seguir trabajando en lugar de detenerse para hacer preguntas aclaratorias (Claude sigue preguntando cuando tu prompt o una skill cuentan con ello). Si la única razón por la que usas bypass es "estoy cansado de las confirmaciones", el modo auto puede ser suficiente. Las acciones que coinciden con una regla ask siguen pidiendo confirmación en el modo auto.
Advertencia importante
Ninguna configuración puede reducir el juicio de seguridad de Claude a cero absoluto. Esto es intencional, no un error ni una limitación. Para operaciones de alto riesgo, que Claude pida confirmación es el comportamiento correcto. Acéptalo como parte del diseño. También la Capa 1 conserva algunas confirmaciones que el bypass no elimina, como las reglas ask y el borrado de rutas críticas.
8. Resumen
| Elemento | Detalle |
|---|---|
| Qué es el bypass | Saltar casi todos los diálogos de confirmación previos a la herramienta (Capa 1) |
| Qué desactiva el bypass | La IU de permisos de herramientas ("¿Puedo ejecutar este comando?"), incluidas las confirmaciones para escribir en rutas protegidas como .git y .claude |
| Qué NO desactiva el bypass | El juicio de seguridad de la IA de Claude (confirmación enviada como texto en el chat) y las excepciones de la Capa 1 (reglas ask, rm/rmdir sobre rutas críticas, AskUserQuestion) |
| Reglas en modo bypass | deny sigue bloqueando; allow no tiene efecto |
| Criterios de confirmación de Claude | Irreversibilidad, alcance del impacto, riesgo de seguridad |
| Cómo reducir las confirmaciones | Contexto en CLAUDE.md / instrucciones específicas / modo auto |
| Por qué dos capas | El permiso de herramienta y el juicio de la IA son conceptos fundamentalmente distintos |
Cuando Claude pide confirmación incluso en modo bypass, no significa que el bypass haya dejado de funcionar: dos sistemas independientes simplemente están haciendo su trabajo. Entender esta distinción te ayuda a predecir el comportamiento de Claude Code con precisión y a usarlo de forma más eficiente.
Para entender las diferencias entre los productos de Claude, consulta Claude.ai vs Claude Code: ¿cuál es la diferencia?.
FAQ
¿Puedo obtener cero confirmaciones con el modo bypass?
Puedes desactivar casi todos los diálogos de la IU de ejecución de herramientas (Capa 1), pero siguen apareciendo las confirmaciones de las acciones que coinciden con una regla ask, de rm o rmdir sobre rutas críticas y de las preguntas mediante AskUserQuestion. Tampoco puedes eliminar por completo las confirmaciones del juicio de seguridad de la IA de la Capa 2. Esto es una función de seguridad intencional. Sin embargo, documentar bien tu entorno en CLAUDE.md y dar instrucciones específicas puede reducir significativamente la frecuencia con la que Claude pregunta.
¿Es un error que Claude pida confirmación?
No. El modo bypass omite la IU de permisos de herramientas, no el juicio de la IA de Claude. Que Claude haga una pausa antes de operaciones irreversibles, entornos de producción o datos sensibles es un comportamiento de seguridad intencional, no un fallo. No es que "el bypass no funcione", sino que "dos sistemas operan de forma independiente". Si en lugar de texto en el chat aparece un diálogo que pide permiso, es una de las confirmaciones de la Capa 1 que el bypass conserva, como una regla ask o el borrado de una ruta crítica.
¿Cómo evito que Claude se detenga en pipelines de CI/CD?
Tres cosas funcionan bien: ① indica explícitamente en CLAUDE.md o en el prompt del sistema que "este es un entorno de CI/CD completamente aislado y todas las operaciones se ejecutan de forma segura", ② da instrucciones de tarea pequeñas y específicas (las instrucciones vagas provocan más confirmaciones), ③ combina el modo bypass con el aislamiento de contenedores Docker. Para el ③, ejecuta Claude Code con un usuario que no sea root: en Linux y macOS, el modo bypass se niega a arrancar como root o con sudo. Con -p, las pocas confirmaciones que el bypass conserva se deniegan en lugar de esperar una respuesta. Si solo quieres que se ejecuten acciones aprobadas de antemano, la documentación oficial también propone --permission-mode dontAsk con --allowedTools para CI. Ten en cuenta que aun con todo esto, puede que Claude siga haciendo alguna pausa.
¿Puedo distinguir visualmente un diálogo de herramienta de la confirmación de Claude?
Sí. Los diálogos de permisos de herramientas de la Capa 1 aparecen en el terminal de Claude Code como una IU interactiva que muestra el comando o la edición junto con opciones como Yes y No. Las confirmaciones del juicio de la IA de la Capa 2 aparecen como texto de conversación normal de Claude (por ejemplo, "Esto modificará la BD de producción — ¿estás de acuerdo?"). El caso que confunde es AskUserQuestion, con la que Claude hace una pregunta con opciones: la pregunta viene de Claude, pero aparece como un diálogo y espera tu respuesta incluso en modo bypass, porque la Capa 1 nunca la aprueba automáticamente. Los formatos de visualización son distintos, por lo que son fáciles de distinguir una vez que te familiarizas con ellos.
