«Con --dangerously-skip-permissions igual no pasa un rm -rf»: lo que está probado y cómo proteger tu máquina

Una ingeniera de Claude Code anunció CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS, una variable que apaga la red de seguridad contra rm -rf ~. Apareció primero en un post y en npm 2.1.311; ahora la documentación oficial la describe. Checklist para --dangerously-skip-permissions.

Seguridad · Yoseph Franco · 27 de octubre de 2026 · 10 min de lectura · Read in English

Ilustración abstracta de una terminal con rm -rf junto a un triángulo de advertencia y un escudo agrietado

En este artículo

Mucha gente que usa Claude Code con --dangerously-skip-permissions da por hecho una de dos cosas: que el modo aprueba absolutamente todo, o que, pase lo que pase, un rm -rf sobre tu home nunca va a correr. Las dos ideas están mal, y desde ayer hay una razón más para revisarlas.

Actualización 27 de octubre de 2026: CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS ya está en la documentación oficial de Claude Code, en variables de entorno y en modos de permisos. Exige Claude Code v2.1.311 o posterior. Con el valor 1, los comandos rm y rmdir de Bash que apuntan a una ruta crítica corren sin aviso, solo en el modo bypassPermissions, no en el modo plan ni en ningún otro modo. Aplica solo a lo que el control de rutas críticas marca en las herramientas Bash y Monitor, incluidos los comandos que Claude Code no llega a analizar por completo. Hay que definirla en el entorno que lanza Claude Code; si está en el bloque env de un archivo de configuración, se ignora. Al iniciar imprime una línea que dice una de estas frases: "is set, so dangerous rm commands can run without a prompt", "has no effect in this session", o "has no effect while the Windows registry cannot be read for managed settings". Advertencia oficial, citada en inglés: "With this variable set, you lose a safety prompt for destructive deletes: a command such as rm -rf ~ can run without asking you. Set it only in an isolated environment whose contents you can afford to lose." Traducción: con esta variable definida se pierde un aviso de seguridad para borrados destructivos; un comando como rm -rf ~ puede ejecutarse sin preguntar. Hay que definirla solo en un entorno aislado cuyo contenido se pueda perder.

La documentación muestra este arranque genérico en macOS, Linux o WSL. La variable se define en esa shell y Claude Code se inicia desde ahí:

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

El lunes 26 de octubre a las 16:09 (hora de Argentina), Daisy Hollman, que se presenta en X como parte del equipo de Claude Code en Anthropic, escribió que --dangerously-skip-permissions "no aprueba realmente TODO": sigue bloqueando cosas obvias como rm -rf ~. Y agregó que la versión de ese día permite desactivar esa protección con una variable nueva: CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1.

Dos avisos antes de seguir. Primero: la variable apareció en ese post el 26 de octubre y en npm 2.1.311. Cuando se publicó esta nota (27 de octubre, 08:45 hora de Argentina) no estaba en la documentación oficial ni en el changelog público. Más tarde, el mismo día, la documentación la incorporó. El changelog público sigue sin mencionar el nombre: la sección 2.1.311 no la nombra, y buscar EVEN_MORE en todo el archivo no da resultados. Segundo: no probé el comportamiento de la variable. Lo que sí hice fue una comprobación propia sobre el paquete publicado, que explico abajo. Lo que hace la variable, en la actualización de arriba, sale de la documentación oficial. El resto de esta nota sale de la documentación y del changelog oficiales.

Qué dijo el post, según Daisy Hollman

El texto original, traducido: "Dato curioso: --dangerously-skip-permissions no aprueba realmente TODO; todavía bloqueamos algunas cosas obvias como rm -rf ~. Pero la versión de hoy te va a permitir desactivar esto si de verdad quieres, con una nueva variable de entorno CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1".

Su bio aclara que las opiniones son personales. Cuando alguien le respondió que esperaba que no fuera una broma, ella contestó: "¡No es una broma!". En el momento en que lo revisé, el post tenía unas 190.000 impresiones y 1.900 "me gusta".

### Del post y de npm a la documentación oficial

Estado: documentada el 27 de octubre de 2026. La versión 2.1.311 del paquete @anthropic-ai/claude-code se publicó en npm el 26 de octubre a las 16:47 (hora de Argentina), unos 38 minutos después del post. Ese fue el primer paquete publicado donde aparece el nombre. Las páginas de variables de entorno y de modos de permisos ahora la describen. La sección 2.1.311 del CHANGELOG oficial sigue sin mencionar la variable, y buscar EVEN_MORE en todo el archivo no da resultados. La página de configuración sigue sin nombrarla; las otras dos dicen que un bloque env de la configuración se ignora.

### Mi comprobación sobre el paquete

Estado: comprobación propia, no documentación. Descargué de npm el binario para Linux x64 de la versión 2.1.311 y busqué el texto. El nombre CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS aparece varias veces, junto a otras variables que ajustan el aviso de rm peligroso. En el binario de la 2.1.310 no aparece. Eso confirma que el nombre ya iba en la 2.1.311. Esa comprobación no dice qué hace. Ahora lo dice la documentación, y yo sigo sin haberla ejecutado.

Lo que sí está documentado: la red de seguridad para rm -rf

Este es el aviso que la variable apaga en el modo bypassPermissions. Según la documentación de modos de permisos:

bypassPermissions (el modo que activa --dangerously-skip-permissions) "desactiva los avisos de permisos y los controles de seguridad", y la documentación lo recomienda solo para "contenedores y máquinas virtuales aislados".
Aun así, hay acciones que ningún modo aprueba solo. Una es lo que la documentación llama critical-path removals: comandos rm y rmdir cuyo objetivo es una ruta crítica. Ninguna regla allow ni ningún hook PreToolUse que responda "allow" las aprueba.
Las rutas críticas incluyen la raíz del sistema de archivos, los directorios de primer nivel como /usr o /etc, tu home, tu directorio de trabajo y sus carpetas padre, y casos trampa como rm -rf "$DIR"/*, que se convierte en un borrado desde la raíz si la variable está vacía.
En bypassPermissions, dentro de la terminal, Claude Code te pide confirmar con una cuenta regresiva de dos minutos. Si nadie responde, deniega el comando y le dice a Claude qué hacer en su lugar. Después de tres avisos sin respuesta en una sesión, deniega los siguientes directamente.

O sea: el post dice "bloqueamos", pero la documentación habla de un aviso que, sin respuesta, termina en denegación. El resultado práctico es parecido. El matiz importa si alguien está mirando la terminal y aprieta "sí" por reflejo.

El giro: la red de seguridad nunca fue un sandbox

La propia documentación lo dice con todas las letras: el control "puede pasar por alto algunos comandos, así que no reemplaza un control del sistema operativo como el sandboxing". Y agrega que un comando que el control no detecta no recibe ningún trato especial, de modo que bypassPermissions lo aprueba sin preguntar. El control solo mira rm y rmdir; otros comandos aprobados también pueden borrar rutas críticas.

Antes de dar acceso

Un correo por semana con lo que pruebo sobre acceso, cuentas y agentes, y la tabla de costo de lista medida (USD de lista, no lo facturado). No es una lista de verificación descargable.

El changelog muestra que esa red se fue remendando versión por versión. La variable nueva no apaga algo perfecto: apaga algo que ya tenía huecos y que se iba cerrando.

La cronología, con recibos

Probado, afirmado y rumor

| Afirmación | Estado | Por qué | | :- | :- | :- | | --dangerously-skip-permissions aprueba todo | Falso | La documentación lista acciones que ningún modo aprueba solo, incluidos los borrados de rutas críticas | | Las reglas deny siguen funcionando en bypass | Probado | La documentación: "Las reglas deny bloquean en todos los modos, incluido bypassPermissions" | | Existe una variable que apaga el aviso de rm -rf ~ en bypassPermissions | Documentado | Lo dice la página de modos de permisos, para Claude Code v2.1.311 o posterior, y solo en ese modo. Apareció primero en el post del 26 de octubre y en el binario 2.1.311. El changelog sigue sin entrada | | La red de seguridad te protege de cualquier borrado | Falso | La documentación dice que puede pasar por alto comandos y que solo mira rm y rmdir | | Un contenedor resuelve todo | Falso | La guía de dev containers advierte que, con bypass, el contenedor no impide sacar lo que haya adentro, incluidas las credenciales de Claude Code en ~/.claude | | Claude Code se niega a correr en bypass como root | Probado | En Linux y macOS rechaza --dangerously-skip-permissions con root o sudo, salvo dentro de un sandbox reconocido |

Checklist para usar --dangerously-skip-permissions sin regalar tu máquina

La lógica es simple: si vas a desactivar una red de seguridad, que el piso sea otro. Los fragmentos son genéricos; ajústalos a tu proyecto.

1. Nunca en tu máquina de todos los días. La documentación lo limita a contenedores, máquinas virtuales o dev containers. Si no tienes eso armado, usa el modo auto o el sandbox de Bash antes que el bypass.

2. Contenedor con usuario sin privilegios. Claude Code ya rechaza el bypass como root. Igual conviene fijarlo tú:

bash docker run --rm -it \ --user 1000:1000 \ -v "$PWD":/workspace -w /workspace \ tu-imagen-con-claude-code \ claude --dangerously-skip-permissions

Monta solo la carpeta del proyecto. Nada de -v "$HOME":....

3. Sin credenciales montadas. Ni ~/.ssh, ni ~/.aws, ni archivos de cloud. La guía de dev containers recomienda tokens con alcance al repositorio o de vida corta, pasados como variables de entorno.

4. Red con lista blanca, no red abierta. Claude Code necesita llegar a la API, así que cortar toda la red no sirve. El contenedor de referencia trae un script init-firewall.sh que limita el tráfico de salida. Para los comandos Bash, el sandbox acepta una lista de dominios:

json { "sandbox": { "enabled": true, "allowUnsandboxedCommands": false, "network": { "allowedDomains": ["github.com", "*.npmjs.org"] } } }

allowUnsandboxedCommands: false apaga el reintento fuera del sandbox, que en bypass se aprobaría sin preguntar.

5. Trabaja en un worktree o desde un commit limpio. Antes de soltar al agente, git status sin cambios pendientes y un commit. O mejor, una rama aparte con el flag de worktrees:

bash git status # que no quede nada sin commitear claude --worktree tarea-refactor

Ojo: un worktree aísla cambios de git, no protege el disco. rm -rf sigue siendo rm -rf.

6. Reglas deny en settings.json. Funcionan incluso en bypass. Sintaxis según la documentación de permisos:

json { "permissions": { "deny": [ "Bash(rm -rf *)", "Bash(rm -fr *)", "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)" ] } }

Límite documentado: una regla Bash compara el texto del comando. Bash(rm *) frena rm -rf build/, pero no /bin/rm -rf build/ ni bash -c 'rm -rf build/'. Es un freno, no una pared.

7. Un hook PreToolUse que bloquee rm -rf. La guía de hooks usa justo este caso: un script que sale con código 2 deniega la llamada y le pasa a Claude el mensaje de stderr. En .claude/settings.json:

json { "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-rm-rf.sh" } ] } ] } }

Y el script, en .claude/hooks/block-rm-rf.sh (necesita jq y permiso de ejecución):

bash #!/bin/bash COMMAND=$(jq -r '.tool_input.command // empty') if echo "$COMMAND" | grep -Eq '(^|[^[:alnum:]_])rm[[:space:]]+-[[:alpha:]]*[rR]'; then echo "Bloqueado: rm recursivo no permitido en esta sesión" >&2 exit 2 fi exit 0

Tiene el mismo límite que las reglas: lee texto. Un script de Python que borra archivos pasa de largo.

8. Respaldos que el agente no pueda tocar. Push a un remoto antes de empezar y copias del disco fuera del alcance del contenedor. Si todo lo demás falla, eso es lo que te salva la tarde.

9. Si administras un equipo, apaga el bypass. permissions.disableBypassPermissionsMode: "disable" en la configuración administrada hace que Claude Code rechace --dangerously-skip-permissions.

10. No actives la variable nueva por curiosidad. La advertencia oficial dice, en inglés: "Set it only in an isolated environment whose contents you can afford to lose." Si de verdad la necesitas, que sea dentro de una máquina virtual descartable, como el usuario que le respondió a Daisy diciendo que levanta una VM nueva por tarea. Fuera de eso, no hay ninguna razón para quitar la última red que queda.

Conclusión

La noticia no es que Anthropic deje apagar la protección contra rm -rf ~. La noticia es que mucha gente se enteró ayer de que esa protección existía, y casi nadie sabía que tiene huecos documentados. Si tu seguridad con --dangerously-skip-permissions dependía de que Claude Code "no deja pasar" un rm -rf, ya dependía de algo que la documentación oficial te dice que no uses como barrera. El aislamiento real está en el contenedor, la red con lista blanca, la falta de credenciales y los respaldos. La variable nueva solo deja eso más a la vista.

Preguntas frecuentes

¿--dangerously-skip-permissions deja pasar un rm -rf? Depende del objetivo. Según la documentación, un rm o rmdir sobre una ruta crítica (raíz, home, directorio de trabajo) pide confirmación en la terminal y se deniega si nadie responde en dos minutos. Un rm -rf sobre otra carpeta, o uno que el control no reconoce, corre sin preguntar.

¿Qué hace CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS? Según la documentación de modos de permisos, con el valor 1 en el entorno de arranque deja correr sin aviso los rm y rmdir de Bash y Monitor que el control de rutas críticas marca, solo en el modo bypassPermissions, no en el modo plan. Exige Claude Code v2.1.311 o posterior, y un bloque env de la configuración se ignora. Apareció primero en el post de Daisy Hollman y en npm 2.1.311. El changelog público sigue sin mencionarla. No probé su comportamiento.

¿Las reglas permissions.deny funcionan en modo bypass? Sí. La documentación dice que las reglas deny bloquean en todos los modos, incluido bypassPermissions. Pero comparan el texto del comando, así que una variante como /bin/rm o bash -c '...' puede esquivarlas.

¿Basta con un contenedor Docker? Ayuda mucho, pero no alcanza solo. La documentación advierte que, con bypass, el contenedor no impide sacar lo que esté adentro, incluidas las credenciales de Claude Code. Súmale usuario sin privilegios, red con lista blanca, nada de credenciales montadas y respaldos.

¿Puedo impedir que alguien de mi equipo use --dangerously-skip-permissions? Sí, con permissions.disableBypassPermissionsMode en "disable" dentro de la configuración administrada.

«Con --dangerously-skip-permissions igual no pasa un rm -rf»: lo que está probado y cómo proteger tu máquina

Qué dijo el post, según Daisy Hollman

Lo que sí está documentado: la red de seguridad para rm -rf

El giro: la red de seguridad nunca fue un sandbox

Antes de dar acceso

La cronología, con recibos

Probado, afirmado y rumor

Checklist para usar --dangerously-skip-permissions sin regalar tu máquina

Conclusión

Preguntas frecuentes

Fuentes

Sigue leyendo

Antes de pedirle a una IA que audite tu código: ¿tu cuenta corre riesgo?

¿Qué ve un agente de IA de tu tarjeta o tu contraseña?

Antes de dar acceso