Claude Code --dangerously-skip-permissions: comando, ajustes y alternativas

El comando para iniciar Claude Code omitiendo las confirmaciones habituales es claude --dangerously-skip-permissions. Hace lo mismo que claude --permission-mode bypassPermissions. En cambio, --allow-dangerously-skip-permissions solo permite elegir ese modo durante la sesión: no lo activa al arrancar. Esta diferencia explica muchas ejecuciones que siguen pidiendo permiso. Modos de permisos y flags oficiales.

Bypass permite ejecutar herramientas y escribir en rutas protegidas sin la aprobación habitual, pero no elimina todas las preguntas ni concede privilegios del sistema operativo. Para unas cuantas ediciones repetitivas, suele bastar acceptEdits; para trabajo sin supervisión, la decisión depende también de qué archivos, servicios y credenciales puede alcanzar el proceso. Las instrucciones siguientes se basan en la documentación consultada el 7 de octubre de 2026, sin ejecutar sesiones reales de bypass.

Comando para activar dangerously-skip-permissions

En una terminal donde Claude Code ya esté instalado, situado en el directorio del proyecto y con la autenticación resuelta, utiliza una de estas dos formas:

claude --dangerously-skip-permissions

claude --permission-mode bypassPermissions

Ambas seleccionan bypassPermissions como modo de inicio. Antes de dar una tarea que modifique archivos, comprueba el modo que muestra la sesión; /permissions permite revisar sus reglas. En el primer inicio interactivo aparece una advertencia de responsabilidad: aceptarla habilita el uso, pero esa aceptación y el modo elegido son estados distintos. Un lanzamiento con -p no muestra ese diálogo; --bg requiere haber aceptado la advertencia previamente. Referencia de la CLI y condiciones de inicio.

Para dejar disponible Bypass sin empezar en él:

claude --allow-dangerously-skip-permissions

El resultado esperado es que puedas seleccionarlo mediante el cambio de modo de la terminal. Si no lo seleccionas, continúas en el modo de inicio aplicable. No hay un flag documentado --skip-permissions que sustituya al nombre completo.

Hay una excepción importante al combinar modos: en la terminal interactiva, tener Bypass habilitado también elimina los bloqueos obligatorios de edición y comandos del modo Plan. La instrucción de elaborar un plan permanece, pero ya no constituye una barrera de solo lectura. En -p, en el SDK y en el chat de VS Code, Plan conserva esos bloqueos. Si necesitas examinar un repositorio sin permitir cambios, no uses la combinación de Plan y habilitación de Bypass en la terminal como garantía. Comportamiento actual de Plan.

En Linux y macOS, el inicio con root o sudo se rechaza salvo que Claude Code reconozca un entorno aislado admitido. Para un contenedor, la recomendación documentada es utilizar un usuario sin privilegios. Desde la versión 2.1.248, --restricted tampoco admite Bypass. Un error de este tipo se resuelve revisando el usuario y el entorno, no añadiendo más variantes del flag.

Configuración: por qué el modo del proyecto puede no aplicarse

En la CLI, el flag explícito de inicio tiene prioridad; después cuentan los ajustes aplicables y, por último, el modo predeterminado integrado. Los valores auto y bypassPermissions de permissions.defaultMode en la configuración del proyecto no se aplican como modo de inicio: un proyecto que declara Bypass arranca en Manual. Los ajustes de usuario, los suministrados mediante --settings y las políticas administradas tienen un tratamiento diferente. Orden y ámbitos de configuración.

Si quieres un inicio explícito para una tarea aislada, el flag anterior evita depender del ajuste del repositorio. También puedes proporcionar un archivo concreto. Por ejemplo, guarda este JSON como permisos-bypass.json en el directorio desde el que vayas a iniciar la CLI:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

Después, en ese mismo directorio:

claude --settings ./permisos-bypass.json

Este ejemplo corresponde al archivo entregado por --settings, no a los ajustes automáticos del proyecto. Selecciona Bypass, siempre que las políticas y condiciones de inicio lo permitan. --settings superpone las claves suministradas; no borra por sí solo toda la configuración restante. Para volver a una sesión con confirmaciones habituales, inicia con claude --permission-mode default. La interfaz llama Manual a ese valor default; manual también es un alias desde la versión 2.1.200. Flags de configuración.

El JSON anterior se ha comprobado como JSON válido, sin probar que un cliente instalado lo acepte ni que una política de tu organización permita activarlo. Evita convertir este archivo en un ajuste global por comodidad: compartirlo o reutilizarlo no reduce el acceso del proceso al ordenador.

Qué modo elegir para aprobar menos acciones

Si tu problema son las confirmaciones frecuentes, elige según qué quieres permitir, no según qué nombre parece más automático. La siguiente tabla describe los modos actuales; no es una clasificación absoluta de seguridad.

Fuente y condiciones: modos de permisos. dontAsk no equivale a Bypass: una ejecución puede continuar y, aun así, no haber completado la operación que se le denegó.

Para ediciones rutinarias, puedes empezar así:

claude --permission-mode acceptEdits

Para solicitar Auto explícitamente:

claude --permission-mode auto

La documentación actual sitúa el inicio integrado en Auto para terminal interactiva y VS Code desde la versión 2.1.283, en todos los planes y proveedores admitidos. Esto no garantiza que cualquier combinación funcione: siguen influyendo el modelo, las versiones mínimas del proveedor, las políticas administradas y la disponibilidad del servicio. Auto es una revisión de decisiones, no un límite del sistema operativo.

En -p y SDK, el valor predeterminado merece atención aparte. Las sesiones que consultan indicadores de disponibilidad normalmente empiezan en Manual; desde 2.1.285, las que no realizan esa consulta empiezan en Auto, sujeto a compatibilidad y política. Las organizaciones aptas para HIPAA tienen un predeterminado Manual específico. Por eso un script que omite --permission-mode puede comportarse de forma distinta según versión y entorno. Disponibilidad e inicio de Auto.

Sin interacción: un ejemplo acotado con dontAsk

Para una tarea de lectura no necesitas conceder Bypass ni herramientas de edición. Este ejemplo de CLI presupone un README.md existente en el directorio de trabajo y una sesión autenticada. Solicita un resumen, deja disponible únicamente la herramienta integrada Read y excluye las herramientas MCP:

claude -p --permission-mode dontAsk \
  --tools "Read" \
  --disallowedTools "mcp__*" \
  "Lee README.md y resume cómo ejecutar las pruebas. Si falta el archivo, indícalo. No ejecutes comandos ni modifiques archivos."

El resultado esperado es un resumen basado en el archivo o una explicación de que no pudo leerse. No es una ejecución de las pruebas. --tools selecciona las herramientas integradas, pero no limita MCP; de ahí la exclusión separada. Este ejemplo es documental y no se ha ejecutado contra un modelo. Tampoco convierte el cliente entero en un proceso aislado: las extensiones y los componentes auxiliares requieren controles propios. Selección de herramientas en la CLI.

Para una tarea que sí necesita comandos, puedes preaprobar operaciones concretas con --allowedTools. Eso evita ciertas solicitudes de permiso, no elimina todas las demás herramientas. En Manual, lo que no esté preaprobado puede seguir preguntando; en dontAsk, una operación que necesite permiso se deniega. Si una prueba queda bloqueada, considera ese paso pendiente: la respuesta final del agente o una salida sin diálogo no demuestra que se haya ejecutado.

Para reducir confirmaciones en un proyecto conocido sin seleccionar Bypass, un archivo de ajustes podría contener:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:unit)"
    ],
    "deny": ["WebFetch"]
  }
}

Guárdalo como permisos-revision.json y suminístralo con claude --settings ./permisos-revision.json únicamente si existen y has revisado esos scripts. Es un ejemplo de preaprobación, no una lista exhaustiva de capacidades: un script llamado lint puede ejecutar código, y denegar WebFetch no impide que Bash u otra herramienta accedan a la red. La sintaxis de ambos JSON se comprobó sin conexión; su eficacia operativa no se ha probado.

Por qué sigue preguntando o deniega una operación

Bypass elimina las aprobaciones ordinarias, pero conserva excepciones. No toda pregunta procede además del sistema de permisos: Claude puede pedirte aclarar una tarea ambigua aunque la llamada a una herramienta no requiera autorización.

Las escrituras en rutas protegidas y los borrados críticos son controles diferentes: el permiso para las primeras no implica aprobar los segundos. Desde 2.1.281, las solicitudes de borrado crítico en terminal con Auto o Bypass caducan a los dos minutos; tras repetirse sin respuesta, se deniegan. En Auto fuera de la terminal se deniegan. PowerShell conserva además rechazos propios para rutas del sistema y ciertos borrados con comodines. No extrapoles una comprobación de rm a todos los comandos capaces de borrar archivos. Excepciones y versiones.

Las reglas ordinarias se evalúan en el orden deny → ask → allow, entre los distintos ámbitos. Una regla allow no anula una deny. Sin embargo, un mod instalado dentro del proceso puede sustituir decisiones mediante tool.check, incluidas algunas denegaciones; las protecciones de hooks administrados y políticas Team/Enterprise tienen condiciones específicas. No trates una regla de texto ni un hook casero como protección universal frente a una extensión que modifica el evaluador. Reglas y excepciones de mods.

VS Code, Desktop y Remote Control: dónde se elige el modo

El flag de la terminal no configura automáticamente una conversación abierta en otra interfaz. Sigue el control del entorno donde se ejecuta la tarea.

Estas condiciones corresponden a las pestañas oficiales de cada interfaz; Code en Desktop y Cowork son entornos distintos. En VS Code, initialPermissionMode, el modo recordado y los predeterminados administrados/de usuario tienen su propio orden. Copiar defaultMode al repositorio no resuelve una discrepancia de inicio en esa extensión.

En Remote Control, la ausencia de un botón Bypass no significa que toda ejecución remota esté necesariamente en Manual. Confirma el modo de la terminal que ejecuta el trabajo. Tampoco presupongas que supervisar desde el móvil cambia el acceso del proceso a archivos o servicios.

Al reanudar, ¿se conserva bypassPermissions?

Depende de qué estés reanudando. Reconectar con una sesión de fondo que sigue ejecutándose conserva su modo. Restaurar una transcripción en una nueva terminal es otra operación: Bypass y Plan se restablecen al modo de inicio de la nueva sesión.

Para restaurar una transcripción y seleccionar Bypass expresamente, la forma documental es:

claude --continue --dangerously-skip-permissions

Esto requiere nuevamente un entorno adecuado y que las políticas permitan el modo. No significa que --continue lo conserve por sí solo. Plan puede restaurarse en determinados -p desde la versión 2.1.246 si hay una herramienta de solicitud de permiso y se cumplen las condiciones de flags, bifurcación y canales descritas en la documentación. Modo de permisos al reanudar.

Qué aislamiento necesitas antes de usar Bypass

Una rama o un worktree permiten separar cambios de Git. No impiden que un proceso lea otros archivos, herede credenciales o acceda a servicios. Para una tarea desatendida con Bypass, necesitas decidir dónde se ejecutará Claude Code y qué recursos quedarán realmente fuera de su alcance.

El sandbox integrado de Claude Code y un contenedor o una máquina virtual no cubren lo mismo:

Fuentes: sandbox integrado y entornos de aislamiento.

El sandbox integrado está desactivado por defecto. Cuando no puede arrancar, puede continuar sin aislamiento salvo que se configure failIfUnavailable. Desactivar allowUnsandboxedCommands cierra la vía de reintento fuera del sandbox, pero no elimina por sí solo comandos excluidos ni activa el aislamiento. Desde 2.1.285, un valor false de usuario prevalece sobre un true del proyecto para esa vía de reintento. En Windows nativo este sandbox no está disponible; WSL2 sí está admitido. El modo de autorización automática del sandbox tampoco es el modo de permisos Auto.

La red tiene una condición especialmente relevante para Bypass: allowedDomains: [] no corta por sí solo toda salida. En Bypass, los destinos no incluidos se aprueban salvo que strictAllowlist o un bloqueo administrado de dominios impongan el límite. Las lecturas por defecto y el entorno heredado pueden incluir credenciales. Una deny de Read no equivale a impedir que cualquier subproceso lea ese archivo. Valores predeterminados, red y límites.

Si eliges un contenedor, revisa estos puntos antes de iniciar:

• Ejecuta Claude Code con un usuario sin privilegios y un directorio de trabajo limitado a la tarea.
• Decide qué montajes pueden escribir en el host. Un montaje del repositorio sigue pudiendo modificar esos archivos reales.
• Evita montar el home, claves SSH, perfiles de nube o el socket de Docker. Un volumen persistente con autenticación o historial también contiene datos sensibles.
• Define los destinos de red necesarios para el proveedor del modelo y la autenticación, además de las dependencias que realmente necesites.
• Conserva un punto de partida recuperable y revisa los cambios antes de trasladarlos a otro entorno. Un diff de Git no recupera una base de datos remota ni deshace una filtración.

La Feature oficial para Dev Containers instala Claude Code, pero no incorpora automáticamente un cortafuegos que deniegue toda salida. Su etiqueta :1.0 fija la versión de la Feature, no la versión de la CLI. El ejemplo con devcontainer.json, Dockerfile y init-firewall.sh necesita adaptación: es un ejemplo funcional, no una imagen base mantenida ni una prueba de aislamiento de tu máquina.

El runtime de sandbox del proceso completo es una vista previa de investigación en fase beta y requiere configurar explícitamente archivos y red. Que arranque no prueba que haya cargado la política prevista. Ninguna de estas opciones convierte Claude Code en un modelo local sin conexión: las instrucciones y el contenido leído que se incorpore al contexto se envían al proveedor configurado. No hemos realizado pruebas de contención ni de extracción de datos.

Preguntas frecuentes

¿dangerously-skip-permissions elimina todas las preguntas?

No. Omite las aprobaciones habituales de herramientas, pero siguen existiendo reglas ask, interacción obligatoria, políticas de conectores, salvaguardas de mensajes entre sesiones y controles de borrados críticos. Claude también puede formular una pregunta para aclarar tu objetivo. Excepciones de Bypass.

¿Por qué no basta con allowedTools?

Porque --allowedTools preaprueba operaciones; no define todas las herramientas que pueden existir. --tools selecciona las integradas y MCP requiere control separado. Además, las reglas Bash coinciden con texto y envoltorios reconocidos, no con todos los efectos posibles de programas indirectos. Permisos y flags de herramientas.

¿Puedo usar Bypass en CI?

La CLI admite ejecuciones -p con Bypass, pero no es un requisito general para CI. Para una tarea limitada, dontAsk y preaprobaciones concretas pueden ser suficientes; si se deniega un paso, debe quedar como pendiente. Si el proceso tiene credenciales de publicación, base de datos o despliegue, Bypass no limita esa autoridad. Separa el trabajo del agente de las acciones que publican o afectan a producción. CLI y aislamiento del proceso.

¿Protege contra instrucciones maliciosas en el repositorio?

No. Bypass cambia la aprobación de herramientas; no garantiza que el modelo ignore instrucciones maliciosas. Un hook o una regla puede bloquear acciones que reconozca, pero no sustituye a un límite real de archivos y red. Para código desconocido, conserva revisión o utiliza un entorno separado con el alcance mínimo. Límites del sandbox.

¿Qué hago si solo quiero editar sin confirmar cada archivo?

Empieza con claude --permission-mode acceptEdits. Autoriza ediciones y operaciones habituales de archivos dentro del ámbito permitido, mientras otras acciones pueden seguir requiriendo permiso. Revisa el modo activo y el alcance de la tarea antes de ampliarlo. Modo acceptEdits.