Claude Code --dangerously-skip-permissions: uso y límites

claude --dangerously-skip-permissions inicia Claude Code en modo bypassPermissions. Elimina las solicitudes de aprobación de rutina para cambios de archivos, comandos de shell y llamadas a herramientas. Úsalo para una tarea delimitada dentro de un entorno desechable cuyos archivos, credenciales y acceso a la red ya hayas limitado. La opción en sí no crea ningún sandbox.

claude --dangerously-skip-permissions

Ese es el comando. Antes de agregarlo a un trabajo desatendido, comprueba a qué puede acceder el proceso. Una aprobación omitida en un repositorio desechable tiene un costo diferente al de una aprobación omitida en una laptop que contiene credenciales de producción.

Aquí explicamos el comando, las alternativas y un flujo de trabajo de ejecución y revisión. Revisamos la documentación de Anthropic el 6 de octubre, 2026. Los ejemplos muestran una configuración; no son resultados de una prueba de seguridad en vivo de Claude Code.

¿Qué hace dangerously-skip-permissions?

La opción selecciona el mismo modo de permisos que claude --permission-mode bypassPermissions. Claude puede seguir trabajando sin las paradas de aprobación habituales. Mantiene la identidad del sistema operativo y el acceso del proceso que iniciaste: no otorga privilegios de root, no inventa credenciales ni crea acceso a una red que tu entorno bloquea. Modos de permisos de Claude Code.

Todavía hay excepciones. Las versiones actuales conservan reglas explícitas de denegación y de pregunta, comprobaciones para ciertas eliminaciones en rutas críticas y acciones que requieren interacción del usuario. No trates esas excepciones como protección para archivos arbitrarios o recursos en la nube. Un comando puede dañar un proyecto sin eliminar la raíz del sistema de archivos.

En particular, el modo bypass puede escribir en .git y .claude sin la solicitud de ruta protegida. Algunos resúmenes de búsqueda sugieren que estas carpetas siempre permanecen protegidas. Eso no es lo que dice la documentación actual. Referencia de permisos.

Considera una solicitud de rutina: "Arregla las pruebas que fallan". Claude podría editar una prueba, instalar un paquete o cambiar la configuración. Si el mismo proceso también puede leer una clave en la nube y llamar a su API, una carpeta local desechable por sí sola no restringe esas acciones remotas. Tu configuración debe limitar ese acceso antes de que comience la ejecución.

Comandos para uso interactivo y desatendido

Iniciar una sesión interactiva

Abre una terminal dentro de tu entorno preparado y ejecuta:

claude --dangerously-skip-permissions

Comprueba el modo de permisos mostrado antes de asignar la tarea. En el primer inicio interactivo, Claude Code puede mostrar una advertencia que debes aceptar. Para un error de root o sudo, usa una cuenta que no sea root dentro del entorno en lugar de cambiar las protecciones del host. Configuración de modo y restricciones de root.

Ejecutar una tarea y capturar su resultado

Para una versión actual de Claude Code con autenticación de clave API:

claude --bare -p \
  "Fix the failing unit test in this checkout. Run the relevant tests. Report changed files and failures. Do not commit or push." \
  --dangerously-skip-permissions \
  --max-turns 12 \
  --output-format json > /tmp/claude-result.json

Aquí, -p ejecuta una tarea no interactiva, y --output-format json hace que su respuesta sea más fácil de recopilar para un runner. --max-turns limita el bucle del agente; no impone una fecha límite de tiempo real en todo el trabajo. Configura esa fecha límite también en tu runner. Referencia de opciones de CLI.

--bare evita cargar los hooks ambientales habituales, los plugins, la memoria y las instrucciones del repositorio. Para la API de Anthropic necesita ANTHROPIC_API_KEY; no usa el inicio de sesión OAuth de tu suscripción. Proporciona esa clave a través de la configuración de secretos del runner. En versiones anteriores, comprueba la compatibilidad antes de copiar este ejemplo. Ejecuciones programáticas y modo bare.

El "No hacer commit ni push" del prompt describe la tarea. Aplica la restricción reteniendo el acceso de escritura al repositorio remoto. Una oración en un prompt no puede reemplazar el alcance de una credencial o una política de red.

Para obtener más información sobre cómo recopilar resultados y manejar trabajos fallidos, consulta nuestra guía headless de Claude Code.

Habilitar bypass para más adelante en la sesión

La opción con nombre similar tiene un efecto diferente:

claude --permission-mode default --allow-dangerously-skip-permissions

--allow-dangerously-skip-permissions hace que el bypass sea seleccionable más adelante; no se inicia en bypass. Usa el ciclo de modos Shift+Tab de la terminal para cambiar. Si la sesión no habilitó el bypass en el inicio, reinicia con la opción de habilitación. Referencia de CLI.

Modo auto vs dangerously-skip-permissions

Usa el modo menos permisivo que te permita terminar la tarea:

Los nombres de los modos y el comportamiento provienen de la referencia de permisos.

El modo auto usa un clasificador separado para revisar acciones como comandos de shell y llamadas a herramientas externas. Puede bloquear una acción y dejar que Claude intente otro enfoque. También puede cometer errores. Anthropic lo describe como una forma de reducir la sobrecarga de aprobación, con compensaciones que la revisión manual y el bypass no comparten. Cómo construyó Anthropic el modo auto.

Si las solicitudes repetitivas son tu problema principal, comienza probando el modo auto donde tu cuenta lo admita:

claude --permission-mode auto

Si tu trabajo solo necesita herramientas conocidas, considera dontAsk con reglas de permiso estrictas. Tiene una propiedad útil para la automatización: la falta de permisos hace que la acción falle en lugar de dejar el trabajo esperando a una persona. Inspecciona las acciones denegadas antes de ampliar las reglas.

¿El sandbox de Claude Code hace que el bypass sea seguro?

El sandbox de Bash integrado de Claude Code restringe el acceso del shell a los archivos y a la red. Su opción de auto-permiso puede aprobar comandos en el sandbox sin una solicitud. Esa opción es independiente del clasificador del modo auto. Configuración del sandbox de Bash.

El sandbox de Bash integrado no aísla toda la aplicación. Las herramientas de archivos, los servidores MCP y los hooks necesitan su propio límite, o un entorno externo que contenga todo el proceso de Claude Code. Una máquina virtual y un contenedor también proporcionan un aislamiento diferente. Elige según el código que pretendas ejecutar y el fallo que puedas tolerar. Comparación de entornos de sandbox.

Comprueba también el comportamiento de reintento. Con el bypass habilitado, un reintento sin sandbox puede ejecutarse sin preguntar. Para las configuraciones compatibles, los siguientes ajustes del sandbox evitan ese reintento y requieren que el sandbox se inicie:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Revisa también cualquier entrada excludedCommands, ya que aún pueden ejecutarse fuera del sandbox de Bash. Para configuraciones aplicadas centralmente, usa una política administrada que el agente no pueda editar. Configuración estricta del sandbox.

Un flujo de trabajo práctico para una ejecución desatendida

Imagina una pequeña tarea para arreglar una prueba fallida. El resultado que deseas es un parche y un informe de prueba. No hay razón para que este trabajo tenga acceso de implementación.

1. Preparar un checkout separado

Crea un contenedor o máquina virtual nuevos y copia el repositorio en un commit conocido. Prefiere una copia a un montaje con permisos de escritura de tu directorio de trabajo principal. Un worktree ayuda a separar los cambios, pero no aísla el sistema operativo ni las credenciales.

Instala el entorno de ejecución y los paquetes requeridos durante la configuración. Registra el commit inicial y las versiones de las herramientas. Usa una cuenta que no sea root para el agente. Si comienzas con un dev container, inspecciona sus montajes: un directorio de host con permisos de escritura expone esos archivos del host a ediciones dentro del contenedor. La guía de dev containers de Anthropic explica la configuración y sus límites.

2. Dar al trabajo solo el acceso que necesita

Pasa la credencial del modelo por separado. Si el repositorio es privado, usa acceso de solo lectura al repositorio para el checkout. Mantén las claves de implementación, tu agente SSH, el socket de Docker y los archivos del directorio de inicio no relacionados fuera del entorno.

Permite el endpoint del modelo y los hosts de paquetes o fuentes que la tarea necesite. Restringe el resto del tráfico saliente en los controles de red del entorno. Si falla la descarga de una dependencia, identifica el host requerido antes de abrir más destinos.

Aquí también es donde decides qué servidores MCP, si los hay, necesita la tarea. Una conexión MCP de base de datos o en la nube agrega capacidades remotas incluso cuando el sistema de archivos local es desechable.

3. Ejecutar una tarea con una condición de finalización clara

Usa el comando headless anterior una vez que la autenticación y las dependencias estén listas. Pon el trabajo bajo un tiempo de espera del runner y captura su estado de salida, stdout y stderr. Mantén el comando de prueba bajo tu control para que el resultado no dependa solo del resumen del agente.

Comienza con un cambio pequeño: una prueba fallida o un error documentado. "Limpiar todo el repositorio" deja demasiado espacio para ediciones que no tenías la intención de revisar.

4. Revisar los archivos reales

Después de que termine el trabajo, inspecciona el checkout:

git status --short
git diff --stat
git diff --check
git diff
git ls-files --others --exclude-standard

El último comando enumera los archivos no rastreados, que un diff simple omite. Inspecciónalos también. Compara el commit final con el commit inicial para que un commit inesperado no oculte los cambios del diff del árbol de trabajo. Vuelve a ejecutar las pruebas relevantes desde tu runner de confianza, luego revisa el parche antes de fusionarlo.

Exporta los archivos que necesites antes de detener el entorno. Mantén las credenciales fuera de los registros y artefactos. Caduca las credenciales de la tarea y destruye el espacio de trabajo desechable después de que el material de revisión esté seguro.

Dónde encajan los Lizard Sandboxes

Sandboxes en Lizard pueden proporcionar el espacio de trabajo remoto para este patrón: crea un entorno, ejecuta una tarea, recopila sus archivos y detenlo. Establece un tiempo de vida explícito para que un runner fallido no deje el entorno ejecutándose indefinidamente. Comienza con el inicio rápido de Sandboxes.

Comprueba el entorno de ejecución antes de elegirlo para tu modelo de amenazas. Los Sandboxes se ejecutan como microVMs de Firecracker, cada una con su propio kernel. Un sandbox que adjunta un Persistent Volume existente respaldado por un pod, o que restaura un snapshot de pod más antiguo, se ejecuta como un pod de Kubernetes (runc) y comparte el kernel del host. En el Lizard SDK, getInfo().runtime te indica cuál obtuviste. Mantén las credenciales limitadas en cualquiera de los dos casos. Consulta la documentación del entorno de ejecución.

La ejecución remota ayuda cuando necesitas un espacio de trabajo nuevo para cada trabajo o muchos trabajos a la vez. Todavía necesita una política de red y un paso de revisión. Un sandbox con un token de base de datos de producción puede acceder a esa base de datos independientemente de dónde se ejecute el sandbox.

Preguntas frecuentes

¿Puedo usar dangerously-skip-permissions por defecto?

Sí. Para un worker dedicado dentro de un contenedor o una máquina virtual, añade esta configuración al archivo ~/.claude/settings.json del usuario que ejecuta el worker:

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

Las nuevas sesiones de terminal comenzarán en modo bypass. Limita este valor predeterminado al worker desechable; para trabajos individuales, usa la opción explícita al iniciar. En las versiones actuales, este valor no habilita bypass desde .claude/settings.json ni .claude/settings.local.json del repositorio. Una política administrada también puede desactivar el modo. Alcance y prioridad de la configuración.

¿Los subagentes heredan los permisos de bypass?

Sí. Según la documentación actual, una conversación principal en modo bypass hace que sus subagentes usen el mismo modo y anula su propia configuración de permisos. Un subagente no es un límite de seguridad separado. Permisos de subagentes.

¿Por qué Claude todavía hace una pregunta?

Una solicitud de aprobación y una pregunta sobre la tarea son diferentes. Algunas acciones requieren interacción incluso en modo bypass, y las reglas de pregunta configuradas aún pueden aplicarse. Lee la solicitud real antes de asumir que la opción falló. Para trabajos desatendidos, especifica el resultado esperado y el comportamiento de fallo por adelantado.

¿La opción hace que Claude Code sea gratuito o elimina los límites de solicitudes?

No. Cambia el manejo de permisos. Tu proveedor de modelos aún controla la autenticación, los cargos por uso y los límites de solicitudes. Los reintentos repetidos pueden usar más tokens incluso cuando no aparece ninguna solicitud de aprobación.

Para el trabajo diario, prueba primero el modo auto o la opción de auto-permiso del sandbox de Bash. Para ejecuciones de bypass desatendidas, haz que el entorno sea desechable, restringe a qué puede acceder y revisa los archivos resultantes antes de que afecten a tu proyecto principal.