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

> El comando claude --dangerously-skip-permissions inicia bypassPermissions. Omite las confirmaciones habituales, pero conserva excepciones; habilitarlo, elegirlo y aislar el proceso son acciones distintas.

- URL: https://blog.laozhang.ai/es/posts/claude-code-dangerously-skip-permissions
- Published: 2026-05-07
- Updated: 2026-10-08
- Author: LaoZhang AI Team (https://blog.laozhang.ai/es/about)
- Topic: Claude Code
- Tags: Claude Code, Permisos, Herramientas de desarrollo, Seguridad

---
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](https://code.claude.com/docs/en/permission-modes).

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:

~~~bash
claude --dangerously-skip-permissions
~~~

~~~bash
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](https://code.claude.com/docs/en/cli-reference) y [condiciones de inicio](https://code.claude.com/docs/en/permission-modes).

Para dejar disponible Bypass sin empezar en él:

~~~bash
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](https://code.claude.com/docs/en/permission-modes).

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](https://code.claude.com/docs/en/permission-modes).

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:

~~~json
{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}
~~~

Después, en ese mismo directorio:

~~~bash
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](https://code.claude.com/docs/en/cli-reference).

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

![Modos de permisos de Claude Code y diferencia entre autorización, selección y aislamiento](https://blog.laozhang.ai/posts/es/claude-code-dangerously-skip-permissions/img/explainer-1.webp)

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.

| Necesidad | Modo | Qué cambia |
| --- | --- | --- |
| Revisar cada operación que lo requiera | Manual, valor `default` | Mantiene las solicitudes de autorización habituales |
| Editar archivos con menos interrupciones | `acceptEdits` | Autoriza ediciones y ciertos comandos habituales de archivos dentro del ámbito permitido; no solo Edit y Write |
| Preparar una estrategia antes de modificar | `plan` | Bloquea ediciones y comandos de modificación, con la excepción de terminal interactiva y Bypass habilitado descrita arriba |
| Dejar que se evalúen las operaciones automáticamente | `auto` | Un clasificador decide; puede bloquear y recurrir a su mecanismo de alternativa |
| Rechazar lo que necesitaría preguntar | `dontAsk` | Conserva lecturas y acciones preaprobadas; deniega las que exigirían interacción |
| Ejecutar sin las aprobaciones ordinarias | `bypassPermissions` | Permite las herramientas normalmente, con excepciones y sin crear aislamiento |

Fuente y condiciones: [modos de permisos](https://code.claude.com/docs/en/permission-modes). **`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í:

~~~bash
claude --permission-mode acceptEdits
~~~

Para solicitar Auto explícitamente:

~~~bash
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](https://code.claude.com/docs/en/permission-modes).

## 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:

~~~bash
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](https://code.claude.com/docs/en/cli-reference).

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:

~~~json
{
  "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.

| Lo que observas | Qué revisar | Siguiente acción |
| --- | --- | --- |
| Sigue en Manual tras pasar un flag | Puede haberse usado `--allow-dangerously-skip-permissions`, que solo habilita la selección | Comprueba el modo activo y el comando de inicio |
| Una herramienta concreta sigue preguntando | Reglas `ask`, herramientas de interacción obligatoria o políticas de conectores | Revisa `/permissions` y conserva la aprobación prevista para esa acción |
| Un borrado crítico se detiene | Las comprobaciones especiales de `rm` y `rmdir` siguen vigentes en Auto y Bypass | Revisa el destino y responde conscientemente; no desactives la guarda para continuar |
| Una lectura fuera del directorio pide autorización | Puede aplicarse `blockReadsOutsideWorkingDirectories` | Limita la tarea al directorio previsto o revisa el acceso concreto |
| Una ejecución `dontAsk` no hace una prueba | El comando requería permiso y fue denegado | Preaprueba solo el comando revisado o ejecuta ese paso con supervisión |
| No aparece Bypass en el editor o el móvil | Cada interfaz tiene controles propios | Usa la fila correspondiente de la sección siguiente |
| El inicio se rechaza con `sudo` o `--restricted` | Son restricciones de lanzamiento, no falta de confirmación | Vuelve a un usuario y modo admitidos |

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](https://code.claude.com/docs/en/permission-modes).

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](https://code.claude.com/docs/en/permissions).

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

![Controles de Bypass según la terminal, el editor, Desktop, la web y Remote Control](https://blog.laozhang.ai/posts/es/claude-code-dangerously-skip-permissions/img/explainer-3.webp)

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.

| Entorno | Cómo interpretar Bypass |
| --- | --- |
| Terminal local | Los flags de inicio seleccionan el modo; la opción `--allow-…` lo habilita para el ciclo de modos |
| Extensión de VS Code | Necesita su opción de permitir Bypass. El modo de inicio depende de los ajustes de usuario, el modo recordado y la política; no lee ajustes del proyecto para decidir el inicio |
| Code en Claude Desktop | Se elige desde el selector; Pro/Max tiene un ajuste de habilitación y Team/Enterprise depende de la política de la organización. Un modo recordado por carpeta puede prevalecer |
| Claude Code en la web | Ofrece Accept edits, Plan y Auto cuando es apto; no permite seleccionar Bypass. Ignora los predeterminados Bypass y dontAsk del repositorio |
| Remote Control desde una aplicación | La aplicación no permite seleccionar Auto ni Bypass. La sesión de terminal puede estar ejecutándose con un modo distinto del que representa la aplicación |
| Terminal de JetBrains | Sigue los controles de la CLI |

Estas condiciones corresponden a [las pestañas oficiales de cada interfaz](https://code.claude.com/docs/en/permission-modes); 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.

| Forma de retomar el trabajo | Comportamiento documentado |
| --- | --- |
| Reconectar a una sesión de fondo todavía activa | Conserva el modo de esa sesión |
| Restaurar por ID, nombre o `--continue` en una terminal nueva | Los modos suelen restaurarse, excepto Bypass y Plan, que vuelven al modo de inicio aplicable |
| Abrir el selector de sesiones al iniciar | Usa el modo de inicio de la sesión nueva |
| Ejecutar `/resume` dentro de una sesión abierta | Conserva el modo de la sesión actual |
| Reanudar con `-p` | Usa los predeterminados de una nueva ejecución `-p`, con excepciones versionadas para Plan |

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

~~~bash
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](https://code.claude.com/docs/en/sessions#permission-mode-on-resume).

## 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:

| Límite | Cobertura y condición que debes comprobar |
| --- | --- |
| Sandbox integrado | Rodea Bash, PowerShell, Monitor y sus procesos hijos. No incluye herramientas de archivos/web, MCP, hooks, LSP, mods ni control de pantalla |
| Aislamiento del proceso completo | Un runtime de sandbox, contenedor o VM puede rodear también herramientas de archivos, MCP y hooks; sus montajes y permisos determinan el límite real |
| Control de red | Debe contemplar destinos autorizados, servicios internos y conexiones para modelo/autenticación; permitir un destino también permite enviarle datos |
| Acceso a credenciales | Las variables heredadas, los archivos montados y el estado persistente pueden seguir otorgando autoridad |

Fuentes: [sandbox integrado](https://code.claude.com/docs/en/sandboxing) y [entornos de aislamiento](https://code.claude.com/docs/en/sandbox-environments).

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](https://code.claude.com/docs/en/sandboxing).

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](https://code.claude.com/docs/en/devcontainer) 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](https://code.claude.com/docs/en/permission-modes).

### ¿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](https://code.claude.com/docs/en/permissions) y [flags de herramientas](https://code.claude.com/docs/en/cli-reference).

### ¿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](https://code.claude.com/docs/en/cli-reference) y [aislamiento del proceso](https://code.claude.com/docs/en/sandbox-environments).

### ¿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](https://code.claude.com/docs/en/sandboxing).

### ¿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](https://code.claude.com/docs/en/permission-modes).

## Fuentes

Páginas externas que cita esta guía, en el orden en que aparecen. Última actualización: 2026-10-08.

- [Modos de permisos y flags oficiales](https://code.claude.com/docs/en/permission-modes) (code.claude.com)
- [Referencia de la CLI](https://code.claude.com/docs/en/cli-reference) (code.claude.com)
- [Reglas y excepciones de mods](https://code.claude.com/docs/en/permissions) (code.claude.com)
- [Modo de permisos al reanudar](https://code.claude.com/docs/en/sessions) (code.claude.com)
- [sandbox integrado](https://code.claude.com/docs/en/sandboxing) (code.claude.com)
- [entornos de aislamiento](https://code.claude.com/docs/en/sandbox-environments) (code.claude.com)
- [Feature oficial para Dev Containers](https://code.claude.com/docs/en/devcontainer) (code.claude.com)