
- Claude Code permite gestionar permisos de acción con varias configuraciones, desde modos manual hasta ejecución total sin confirmación.
- Desactivar confirmaciones multiplica la productividad en automatización, pero implica riesgos serios sobre seguridad, integridad de datos y exposición de credenciales, incluso si crees controlar el entorno.
- Existen alternativas progresivas como modo automático, listas blancas de comandos o restricciones por directorio, que equilibran agilidad y protección según cada escenario.
¿Harto de que Claude Code te pregunte “¿Seguro que quieres hacerlo?” antes de cada acción? Si alguna vez has trabajado en proyectos larguísimos o has querido ejecutar automatizaciones en pipelines, sabes que esas confirmaciones, aunque diseñadas para protegerte, pueden convertirse en un auténtico lastre cuando necesitas rapidez y tienes todo bajo control.
Pero la realidad es que darle vía libre total a un agente como Claude Code tiene consecuencias: puedes acelerar procesos hasta el infinito, pero a cambio pierdes tu red de seguridad. A lo largo de este artículo descubrirás cómo configurar Claude Code para trabajar sin pausa, cómo evitar las confirmaciones de permiso, en qué escenarios es sensato activar el modo sin confirmación, los riesgos que implica, y sobre todo, qué alternativas existen para no acabar lamentando un ‘sí a todo’.
Índice
- 1 ¿Por qué Claude Code pide confirmación por defecto?
- 2 ¿Qué acciones requieren confirmación en Claude Code y cómo se categorizan?
- 3 Modos de permisos de Claude Code: manual, automático, bypass y personalizados
- 4 ¿Qué hace exactamente el flag –dangerously-skip-permissions?
- 5 ¿Cuándo tiene sentido usar –dangerously-skip-permissions?
- 6 Riesgos de seguridad al ejecutar Claude Code sin confirmación
- 7 Casos documentados de daños por omisión de permisos en Claude Code
- 8 Cómo y dónde activar/desactivar la confirmación en Claude Code
- 9 Restricciones, rutas y acciones que nunca se saltan la confirmación (incluso en bypass)
- 10 Comparativa de modos y cuándo usar cada uno
- 11 Alternativas seguras al modo sin confirmaciones
- 12 Buenas prácticas y escenarios recomendados
- 13 Implementaciones y recomendaciones a gran escala: el ejemplo de TrueFoundry
- 14 Tutoriales de aplicación y configuración paso a paso
- 15 Preguntas frecuentes sobre permisos y confirmaciones en Claude Code
- 16 Qué bloquea el clasificador y cómo proteger adicionalmente tu proyecto
- 17 Recomendaciones clave al trabajar sin confirmaciones
¿Por qué Claude Code pide confirmación por defecto?
Claude Code está diseñado para priorizar la seguridad del usuario y la integridad del sistema. Es una herramienta capaz de editar archivos, ejecutar scripts, invocar APIs externas y manipular partes sensibles del sistema. Por defecto, actúa en modo manual, pidiéndote confirmación antes de ejecutar cualquier acción que pueda alterar datos, modificar archivos o desencadenar comandos potencialmente peligrosos.
Este enfoque busca prevenir errores fatales, daños accidentales y ataques por inyección de instrucciones maliciosas. Cada vez que Claude Code detecta una operación de escritura, ejecución o acceso a un recurso sensible, se detiene para esperar tu “ok” explícito. Si te parece un fastidio, piensa que es la última defensa antes de que algo que no esperabas borre media base de datos, elimine tu directorio de trabajo o, peor aún, filtre credenciales.
No obstante, cuando necesitas automatización real –sobre todo en CI/CD, contenedores o análisis a escala– este nivel de protección frena el auténtico potencial de Claude Code.
¿Qué acciones requieren confirmación en Claude Code y cómo se categorizan?
Claude Code clasifica las acciones en tres grandes niveles, con actuaciones diferentes en cada caso:
- Operaciones de solo lectura: incluyen lecturas de archivos, búsqueda de texto, análisis de código y navegación. No alteran el estado del sistema. Claude ejecuta estas sin pedirte confirmación.
- Operaciones de escritura o ejecución: aquí entran la edición de archivos, creación de carpetas, ejecución de comandos shell, instalación de paquetes y llamadas a servicios externos. Claude espera tu aprobación antes de actuar.
- Operaciones delicadas o críticas: cualquier acceso a credenciales, variables sensibles, destrucción de datos, acceso a controles remotos inseguros y borrados masivos desencadena una comprobación y confirmación obligatoria.
Esta política puede hacer que una simple refactorización genere decenas de prompts, y por ello muchos acaban aceptando automáticamente sin leer… un riesgo enorme.
Modos de permisos de Claude Code: manual, automático, bypass y personalizados
La arquitectura de permisos de Claude Code es increíblemente flexible. Permite desde el máximo control (manual) hasta la ejecución autónoma total. Los modos clave son:
- Manual (default/manual): Solicita confirmación en cada acción de escritura, ejecución o acceso relevante.
- Auto (auto/automatic): Un segundo modelo de clasificación revisa cada acción y decide si es segura. La mayoría de operaciones “normales” se ejecutan sin interacción, pero acciones dudosas se bloquean o requieren revisión adicional.
- Aceptación de ediciones (acceptEdits): Permite editar archivos sin confirmación, pero detiene la ejecución de comandos, invocaciones shell o llamadas de red.
- Plan (plan): Solo permite análisis y generación de planes de ejecución. No se realizan cambios de estado hasta que revisas y aceptas el plan propuesto.
- Modo sin confirmaciones totales (bypassPermissions o con el flag –dangerously-skip-permissions): Desactiva toda confirmación y control (con matices, como te explicaremos más abajo). Pensado solo para entornos totalmente aislados y desechables.
¿Qué hace exactamente el flag –dangerously-skip-permissions?
El flag --dangerously-skip-permissions es la llave maestra para eliminar todos los bloques de confirmación de Claude Code. Es deliberadamente alarmante en el nombre (no es simplemente –yes, –accept-all ni variantes abreviadas): si lo usas, Claude ejecutará cualquier operación de escritura, comando, borrado o llamada de red sin esperar tu permiso. Todo está permitido al instante dentro de las reglas de entorno.
Su funcionamiento es idéntico a pasar en configuración --permission-mode bypassPermissions o poner «defaultMode»: «bypassPermissions» en tu fichero de settings.json.
Sin embargo, existen excepciones importantes:
- A partir de la versión 2.1.78, algunas rutas protegidas como
.git/,.claude/,.vscode/,.husky/no pueden saltarse el prompt, incluso en modo bypass, salvo determinadas subcarpetas internas necesarias para la operativa de Claude. - No está permitido cambiar a bypassPermissions una vez iniciada la sesión si no arrancaste con ese modo.
- Los administradores pueden vetar este modo para toda la organización desde configuración gestionada.
- Los ganchos personalizados tipo PreToolUse y reglas en denegación siguen evaluándose antes de permitir la acción.
En resumen: no anula todas las reglas de seguridad internas ni los mecanismos de administración, sólo las confirmaciones interactivas para acciones estándar.
¿Cuándo tiene sentido usar –dangerously-skip-permissions?
Existen casos reales y legítimos, aunque tangenciales, donde este modo cobra sentido y elimina mucha fricción:
- Automatización en pipelines CI/CD: No hay interacción humana posible. Necesitas que Claude Code funcione sin bloquear la ejecución. El propio pipeline (o el contenedor donde corre) debe ser la red de seguridad.
- Entornos de contenedores/VMs desechables (Docker, Kubernetes, DevContainer): Si el entorno está completamente aislado, sin acceso a datos críticos ni credenciales, la confirmación sólo añade ruido y puedes controlarlo todo externamente.
- Grandes refactorizaciones o tareas de batch donde revisar cada confirmación es absurdo: Trabajas en una rama o instancia secundaria, ejecutas Claude Code con la omisión de confirmaciones, y git (o tu snapshot) asume la función de recuperación ante error.
La clave es no usarlo nunca en una máquina real, en entornos compartidos, ni con acceso a producción, archivos personales o recursos globales.
Riesgos de seguridad al ejecutar Claude Code sin confirmación
Quitar todas las confirmaciones equivale a darle un cheque en blanco a un agente autónomo con poder de edición y ejecución. Estos son los principales peligros:
- Inyección de instrucciones maliciosas: Si Claude Code accede a documentos, archivos de repositorios, descripciones de PRs o tickets con instrucciones ocultas hostiles (ataques de supply chain, ingeniería social…), ejecutará literalmente lo que encuentre si no tiene que confirmarlo.
- Eliminación o corrupción silenciosa de archivos: Comandos como
rm -rf ~o globs mal construidos pueden destruir directorios enteros en segundos. El historial de errores muestra múltiples casos reales de borrados masivos (consultar por ejemplo el bug report #3905), y lo más peligroso es la explotación indirecta: una shell puede expandir variables o comodines a rutas críticas sin que tú te des cuenta. - Vulnerabilidad a filtraciones de credenciales: Claude Code puede volcar variables sensibles, credenciales en logs o archivos de salida, enviar datos a endpoints externos accidentalmente o por error de instrucción.
- Acceso sin límites a infraestructura compartida: Si tu sesión es secuestrada (por ejemplo, alguien intercepta el prompt, craquea el workspace o ataca el entorno), el agente tendrá carta blanca para manipular lo que alcance.
Una simple instrucción mal entendida puede escalar en cuestión de segundos a una pérdida total de datos o exposición catastrófica… y al no requerirse confirmación, descubrirás el error cuando ya sea tarde.
Casos documentados de daños por omisión de permisos en Claude Code
Hay decenas de incidentes reales –algunos reconocidos públicamente por Anthropic o su comunidad– que muestran los peligros de usar --dangerously-skip-permissions sin entorno controlado:
- El clásico rm -rf ~ escapado en un script: Eliminaciones masivas de todo el directorio personal del usuario por expansión incorrecta de comodines. Casos divulgados en hacker news, Reddit y registros públicos.
- Borrados en raíz de sistema: Ejecución de
rm -rf /durante operaciones de reconstrucción, resultando en el borrado de ficheros del sistema y home del usuario. El error #10077 de GitHub narra con detalle el desastre: miles de mensajes de “Permiso denegado” y pérdida total de datos. - Corrupción silenciosa de configuración: Sobrescribir archivos existentes con valores vacíos o inconsistentes, sin ningún registro ni posibilidad de revertir, especialmente en directorios de configuración o rutas especiales.
- Filtrado accidental de secretos y variables de entorno: Instrucciones que, sin chequeo, acaban enviando datos sensibles a endpoints externos o escribiéndolos en lugares públicos.
- Cadenas de errores por expansión de rutas mal interpretadas: Bugs sutiles pueden disparar borrados en cadenas (ej: un script hace rm -rf * en un lugar inesperado), agravando la pérdida de información.
Es importante recalcar que algunos de estos incidentes se han producido incluso con el sistema de permisos activo, lo que demuestra que ningún método es infalible… pero desactivarlo lo expone todo.
Cómo y dónde activar/desactivar la confirmación en Claude Code
Tienes varias formas para controlar cuándo Claude Code pide tu permiso. Según el caso, puedes hacer la omisión puntual o aplicar políticas persistentes a todo un proyecto o máquina.
Mediante atajo de teclado en sesión interactiva
- Pulsa Shift+Tab durante cualquier sesión activa para cambiar entre modos: manual, auto-edits y solo lectura (según versión y configuración). El modo seleccionado aparece destacado en la interfaz. Es útil para tareas puntuales donde confías en el contexto actual.
Fichero settings.json para proyectos o usuarios
- Coloca un .claude/settings.json en el raíz del proyecto (o ~/.claude/settings.json para que aplique a toda tu máquina):
{ "permissions": { "allow": } }Esto autoriza cualquier edición o comando bash sin confirmación en el alcance especificado.
- Para hacerlo granular (más seguro):
{ "permissions": { "allow": } }Así solo permites omitir confirmación a comandos/git/npm y edición en src/.
Flag –dangerously-skip-permissions en CLI o CI/CD
- Lanza Claude Code con la bandera al ejecutar en scripts headless:
claude --dangerously-skip-permissions -p "Comando a ejecutar" - Perfecto para pipelines y workflows desatendidos, siempre bajo entorno aislado.
- No use este método en sesiones normales o con acceso a datos reales
Restricciones, rutas y acciones que nunca se saltan la confirmación (incluso en bypass)
El modo bypass (o el flag de omisión total) no puede saltarse ciertas salvaguardas críticas impuestas por Claude Code y su configuración.
- Rutas protegidas: Archivos y directorios vitales como
.git/,.config/git/,.vscode/,.husky/,.claude/(con matices), y otros, nunca se sobrescriben automáticamente salvo subdirectorios explícitos donde Claude necesita operar. - Comandos destructivos: Operaciones como
rm -rf /,rm -rf ~o eliminaciones en directorios padres son denegadas automáticamente. - Límites y reglas explícitas: La configuración de permisos puede incluir listas de denegación (
deny) o reglas deaskque imponen chequeos sin importar el modo activo (ej:Bash(rm: *)para vetar borrados masivos incluso en modo bypass). - Herramientas que requieren interacción: Algunas funciones conectadas con otras herramientas (MCP, conectores de la organización, hooks de validación) obligan a un mínimo de control; Claude Code las evalúa y puede bloquearlas/solicitar permiso siempre.
Comparativa de modos y cuándo usar cada uno
| Situación | Modo recomendado |
|---|---|
| Sesión manual, analizando cambios delicados | Manual (por defecto) |
| Refactorización masiva o automatización confiable | AcceptEdits / auto-edits con restricciones |
| Pipeline CI/CD, contenedor desechable | BypassPermissions / dangerously-skip-permissions |
| Proyecto crítico o con credenciales/sensibles | Manual / modo restrictivo |
Alternativas seguras al modo sin confirmaciones
Claude Code dispone de alternativas más seguras si solo buscas reducir la fricción, pero no eliminar toda protección:
Modo automático (auto)
- Un modelo clasificador revisa cada acción. Las operaciones estándar se ejecutan automáticamente, pero bloquea o solicita confirmación en acciones de riesgo (elévele a clasificación en tiempo real).
- Impide ampliación del alcance más allá de la intención del usuario, acceso a infraestructuras no confiables o acciones motivadas por inputs hostiles.
- Bloquea por defecto comandos destructivos, publicación de secretos, mutaciones fuera del repo, y muchas acciones que impliquen dataleaks o cambios masivos.
- Apropiado si quieres equilibrio entre agilidad y control humano real.
Listas de permisos personalizadas
- Configura
allowydenyen settings.json para autorizar sólo determinados comandos, directorios o herramientas. - También puedes autorizar ediciones en rutas específicas mientras mantienes vetados el resto de comandos o accesos críticos.
- Bloquea combinaciones de comandos peligrosos aunque tengas la omisión activa.
Modo AcceptEdits
- Aprueba automáticamente la edición de archivos, pero no comandos bash ni acciones de ejecución.
- Idóneo para sesiones de trabajo en las que sólo la manipulación de ficheros resulta repetitiva.
Modo Plan
- Permite explorar, razonar y examinar la propuesta de cambios antes de que Claude Code actúe.
- No hay cambios ni ejecuciones hasta que apruebes el plan global.
Hooks y ganchos de control
- Un hook PreToolUse puede bloquear llamadas a herramientas peligrosas, validar contexto antes de cualquier petición, y actúa en todos los modos, incluso bypass.
- Muchos equipos añaden hooks para bloquear patrones sensibles y evitar riesgos de comandos destructivos incluso si alguien lanza una sesión en modo sin confirmación.
Restricción de directorios montados
- Limita qué directorios están disponibles para Claude Code durante una sesión.
- Así puedes reducir la exposición potencial incluso aunque elimines las confirmaciones de permiso.
Buenas prácticas y escenarios recomendados
Si decides trabajar sin confirmación, no lo hagas nunca sin cubrir estos puntos:
- Usa siempre ramas secundarias en git (o entornos desechables): Si algo sale mal, puedes revertir sin drama.
- Revisa los cambios globales con
/reviewo herramientas similares, incluso tras dar permiso general: Así detectas corrupciones antes de que pasen a master/main o despliegues productivos. - Jamás ejecutes modo bypass en tu home directory o fuera de un entorno acotado: Es la puerta abierta a pérdidas irrecuperables.
- En pipelines, asegúrate de que no se cargan variables de entorno ni archivos de configuración sensibles: Así evitas leaks accidentales aún sin confirmación.
- Aplica controles de red: el aislamiento a nivel de VPC, cortafuegos o configuración del contenedor es indispensable.
- Coloca reglas restrictivas previas (
deny,ask) siempre en proyectos delicados.
Implementaciones y recomendaciones a gran escala: el ejemplo de TrueFoundry
Plataformas como TrueFoundry implementan control granular a nivel de infraestructura para eliminar la necesidad de usar flags peligrosos como --dangerously-skip-permissions en producción.
- Ejecución aislada en VPC o entornos cloud sin salida externa por defecto; así, aunque un agente escale permisos, nunca puede afectar más de lo aislado.
- Inyección de credenciales contextual y efímera, minimizando la superficie de ataque.
- Auditoría completa de acciones, políticas RBAC y restricciones de uso por agente, tarea y entorno.
- Listas de control granular de herramientas disponibles por sesión, bloqueando potenciales flujos inseguros desde la infraestructura.
Este enfoque ha permitido a empresas migrar flujos enteros de automatización de Claude Code sin necesidad de desactivar globalmente las salvaguardas de confirmación, delegando la contención a la infraestructura TI.
Tutoriales de aplicación y configuración paso a paso
1. Cambio temporal de permisos durante la sesión:
- En una terminal interactiva: pulsa Shift+Tab para alternar entre Manual, AcceptEdits y sólo lectura.
- Si seleccionas AcceptEdits, Claude editará archivos automáticamente pero preguntará antes de ejecutar comandos externos o red.
- Para volver a modo seguro, pulsa de nuevo Shift+Tab hasta ver la indicación manual en el prompt.
2. Configuración persistente en settings.json:
- Crea o edita
.claude/settings.jsony añade:{ "permissions": { "allow": } } - En entorno global, haz la edición en
~/.claude/settings.json. Eso aplica a toda tu máquina. - Recuerda que el entorno del proyecto prevalece sobre el global si ambos existen.
3. Ejecución desatendida en CI/CD:
- En workflows como GitHub Actions:
- name: Fix tests with Claude Code env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} run: | claude --dangerously-skip-permissions -p \ "Analiza los tests fallidos y corrígelos. \ Haz commit de los cambios con mensaje 'fix: automated test corrections'" - ¡Sé estricto! Hazlo sólo en entornos efímeros con aislamiento real, backup y control de contexto.
Preguntas frecuentes sobre permisos y confirmaciones en Claude Code
- ¿Puedo cambiar a bypassPermissions a mitad de sesión?
- No. El modo debe fijarse al arrancar la sesión; si quieres omitir confirmación, reinicia desde el principio con el flag/exacta configuración.
- ¿Qué sucede si tengo
bypassPermissionsen settings.json, pero mi entorno lo ignora? - Claude Code ignora esta configuración en sesiones web/cloud. Solo se aplica en terminales locales o desktop con configuración explícita aplicada.
- ¿Los hooks y reglas de deny siguen aplicándose en bypass?
- Sí, siempre. Los hooks (como PreToolUse) y las listas de herramientas prohibidas se evalúan antes que cualquier modo de permisos.
- ¿Puedo hacer que Claude Code sólo deje de pedir confirmación para algunos comandos, pero no para todos?
- Sí. Crea reglas granulares con allow/deny en settings.json, por acción, comando o directorio. Ejemplo: sólo permites
Bash(git *)yEdit(src/*)para ejecutar sin confirmar. - ¿Puedo confiar ciegamente en el modo automático?
- No hay sistema perfecto: el clasificador mejora la seguridad, pero no te garantiza cero falsos positivos ni false negatives. Ante cambios de alto riesgo, sigue revisando.
Qué bloquea el clasificador y cómo proteger adicionalmente tu proyecto
El modelo automático bloquea, además de comandos clásicos peligrosos, toda acción que implique:
- Descarga y ejecución arbitraria de código (
curl | bash), instalación de paquetes inseguros. - Publicación o envío de datos a endpoints externos sospechosos.
- Acción que implique escalada de privilegios, alteración de infraestructura, deployment a producción.
- Borrado/destrucción de recursos persistentes.
- Filtrado de datos personales, secretos o rutas marcadas como sensibles.
- Túneles, shells inversos o redirecciones fuera del entorno de confianza.
Puedes consultar (y ampliar) patrones bloqueados ejecutando claude auto-mode defaults para revisar las reglas completas en tu instalación.
Recomendaciones clave al trabajar sin confirmaciones
- Limita la cobertura de auto-aprobaciones a directorios y comandos específicos siempre que sea posible.
- En entorno CI, asegúrate de que no se filtran variables sensibles ni se permita salida de red salvo hacia destinos controlados.
- Combina los backups y puntos de control de Git con snapshots automáticos en cloud/container.
- Nunca utilices la omisión de confirmaciones “a pelo” en tu entorno doméstico, portátil de trabajo o máquina compartida.
- Valora añadir hooks preventivos para evitar comandos destructivos, incluso si confías en todo lo anterior.
Erradicar el ciclo de confirmación de Claude Code puede ser la solución definitiva en entornos controlados, automatizaciones, grandes tareas repetitivas o cuando cada segundo de espera cuenta, pero siempre debe implementarse con medidas complementarias de aislamiento, control y backups. Hay alternativas progresivas para casi cualquier escenario, desde el modo automático al uso de listas allow/deny, sin tener por qué quitarte la red de seguridad.
Antes de dar carta blanca, asegúrate de entender los riesgos, de tener el entorno acordonado y de saber exactamente qué comandos va a ejecutar tu agente. Solo así podrás desbloquear la verdadera potencia de Claude Code sin llevarte el susto del siglo.
Guía completa sobre Gemini Antigravity: el IDE de IA que está cambiando el desarrollo







