CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS: uso y auditoría
Claude Code v2.1.311+ permite eliminar la confirmación para borrar rutas críticas en bypassPermissions. Revisa cómo activarlo al iniciar, qué significan los tres avisos, por qué puede no funcionar y cómo proteger los equipos y CI.
Índice
Deja sin definir CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS en las máquinas de desarrollo y los runners compartidos de CI. En Claude Code v2.1.311+, elimina una confirmación de borrado concreta solo cuando la sesión usa bypassPermissions. Resérvala para entornos desechables y aislados donde sea aceptable perder cualquier archivo con permiso de escritura.
A fecha de 2026-10-28, Anthropic documenta esta opción como una variable del entorno de lanzamiento. No activa el modo de omisión de permisos ni deshabilita todos los demás controles.
¿Por qué el modo peligroso sigue bloqueando rm -rf ~?
Claude Code comprueba los destinos reconocidos de rm y rmdir por separado de las autorizaciones habituales de herramientas. La opción --dangerously-skip-permissions selecciona bypassPermissions, pero ese modo conserva la comprobación de rutas críticas salvo que la nueva variable surta efecto.
Una regla allow no puede autorizar un borrado que Claude Code reconozca como dirigido a una ruta crítica. Tampoco puede hacerlo un hook PreToolUse que devuelva allow. De forma predeterminada, el terminal pide autorización con una cuenta atrás de dos minutos.
En una ejecución con -p, una herramienta de permisos, un callback del SDK o un hook PermissionRequest que autorice pueden decidir la operación. Sin uno de estos mecanismos, el resultado predeterminado es la denegación.
La definición de rutas críticas incluye:
- La raíz del sistema de archivos, como
/. - Los directorios directamente bajo la raíz, incluidos
/usr,/etcy/data. - Tu directorio personal, incluido su nombre corto de Windows 8.3, como
C:\Users\LONGNA~1. - Las raíces de las unidades de Windows y sus directorios de primer nivel, como
C:\yC:\Windows. También cuentan formas equivalentes como\\?\C:\y\\localhost\C$. - Tu directorio de trabajo y sus directorios padre.
- Los directorios de trabajo adicionales y sus directorios padre, concretamente cuando el destino es un patrón glob bajo ellos, como
rm -rf <dir>/*.
Borrar el propio directorio adicional con rm -rf <dir> no activa esa comprobación específica. Aun así, puede aplicarse otra regla, por ejemplo, si también es un directorio de primer nivel.
Esta comprobación cubre los comandos que Claude Code reconoce. Un comando que pase inadvertido no recibe protección especial, y otros programas autorizados también pueden borrar archivos. Remove-Item de PowerShell y los comandos de borrado de cmd tienen comprobaciones independientes.
Actívala para una sola sesión de terminal aislada
Define la variable en el entorno que inicia claude y selecciona bypassPermissions de forma explícita. Un caso apropiado es un trabajo automatizado que vacía deliberadamente un directorio de trabajo desechable.
Necesitas una CLI operativa, autenticada y de la versión v2.1.311 o posterior. Ejecuta estas comprobaciones en Bash sobre macOS, Linux o WSL:
claude --version
claude auth status --textSi falla la autenticación, usa claude auth login con la configuración de cuenta autorizada. Si se ejecuta el binario equivocado, sigue las comprobaciones de instalación y PATH de Claude Code. Actualiza cualquier instalación anterior antes de continuar.
Inicia la sesión deseada con una asignación temporal de Bash:
CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
claude --permission-mode bypassPermissionsLa asignación se aplica a este comando y a sus procesos hijos. No permanece en el shell padre. Puedes sustituir --permission-mode bypassPermissions por --dangerously-skip-permissions.
Usa un usuario que no sea root en el entorno aislado. En Linux y macOS, este modo normalmente rechaza los inicios como root o mediante sudo, salvo en sandboxes reconocidos.
No pongas esta variable en el bloque env de ~/.claude/settings.json, .claude/settings.json o .claude/settings.local.json. La referencia de variables de entorno confirma que Claude Code la ignora en esos archivos. Moverla entre ámbitos de configuración no lo solucionará.
La opción solo se aplica mientras la sesión está realmente en bypassPermissions, no en plan. Su alcance es la comprobación de rutas críticas de las herramientas Bash y Monitor, incluidos los comandos que esa comprobación no puede analizar por completo.
Para quitar una variable ya exportada, sal de la sesión afectada y elimina la asignación de la fuente que la establece al iniciar. Ejecuta unset CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS en tu shell y abre una sesión nueva.
Comprueba el aviso de inicio sin borrar nada
Lee el aviso de inicio de Claude Code para comprobar si la opción puede surtir efecto. Una respuesta correcta del modelo no basta para determinar el estado de sus permisos.
Para realizar un diagnóstico breve en el entorno aislado, ejecuta lo siguiente en Bash:
CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
claude --permission-mode bypassPermissions \
--tools "" --disallowedTools "mcp__*" \
-p "Reply with READY." 2>claude-startup.log
grep -F 'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' claude-startup.logLas opciones de la CLI retiran las herramientas integradas y deniegan las herramientas MCP para este diagnóstico. Restringen las herramientas que puede llamar el modelo; los hooks de inicio y las extensiones siguen cargándose.
El comando solicita una respuesta READY en stdout. Guarda la salida de inicio de stderr en claude-startup.log sin pedir ningún borrado.
Los avisos documentados contienen una de estas tres frases:
| Fragmento del aviso | Significado |
|---|---|
is set, so dangerous rm commands can run without a prompt | La opción puede aplicarse cuando se hayan cargado la configuración administrada y los hooks de plugins. Las reglas o los hooks pertinentes todavía pueden impedirlo. |
has no effect in this session | La confirmación o denegación habitual se mantiene durante esta sesión. Corrige la causa y reinicia. |
has no effect while the Windows registry cannot be read for managed settings | Las comprobaciones habituales se mantienen mientras falle la consulta al registro. Una consulta posterior correcta puede activar la opción sin reiniciar. |
En una aplicación del Agent SDK, proporciona la opción stderr para recibir el aviso. La ausencia de salida no demuestra que siga activa la confirmación para rutas críticas. Comprueba la herencia de la variable al iniciar, el modo de permisos activo y si la sesión se inició de forma indirecta.
Si el diagnóstico termina antes de mostrar un aviso, revisa primero el error de inicio. Un fallo de autenticación o configuración es independiente de esta opción de permisos.
Nueve motivos por los que la variable no tiene efecto
Comprueba la versión, el entorno de lanzamiento y el modo activo antes de cambiar otra configuración. Después, compara tu caso con las excepciones documentadas.
Son causas alternativas. Conserva las protecciones que el equipo haya establecido deliberadamente.
| Causa | Qué comprobar y qué hacer |
|---|---|
| 1. Otro componente gestiona las solicitudes de permiso | Revisa --permission-prompt-tool o un callback canUseTool del SDK sin --permission-prompts none. Comprueba también cualquier hook PermissionRequest, independientemente de su matcher, o un mod que gestione ese evento. Retira el manejador que no debería estar activo y reinicia. |
| 2. La sesión se ejecuta en un panel gráfico de chat | El panel de chat de la extensión de VS Code y la aplicación Desktop no aplican esta opción. Inicia la CLI desde tu propio terminal; también sirve el terminal integrado de un IDE. |
3. Una regla deny o ask afecta a Bash, Edit o Read | Cualquier regla de este tipo desactiva la opción, aunque no esté relacionada con el borrado. Una vez leída, su efecto dura toda la sesión, incluso si después la eliminas. Un cambio autorizado de la regla requiere reiniciar. Para omitir una herramienta, usa --tools en lugar de una regla deny. |
| 4. Se bloquean las lecturas fuera de los directorios de trabajo | Revisa permissions.blockReadsOutsideWorkingDirectories. Si corresponde desactivarlo, elimina todos los ajustes que lo establezcan en true y reinicia. |
| 5. Claude Code se inició dentro de otra sesión | Iniciarlo desde la herramienta Bash o un hook de otra sesión conserva las comprobaciones habituales, incluso con la variable en el comando. Inícialo desde tu propio shell. Esta restricción de sesiones anidadas no es una barrera de seguridad. |
6. Un hook PreToolUse devuelve ask | Revisa la decisión del hook para ese borrado. Corrige una respuesta ask no deseada; una respuesta allow por sí sola no anula la comprobación habitual de rutas críticas. |
| 7. Claude Code creó la sesión | Las sesiones en segundo plano creadas por Claude Code empiezan sin la variable. Lo mismo ocurre con las sesiones de agentes de un equipo en paneles divididos y las creadas por un servidor Remote Control. Cuando necesites esta opción, inicia la sesión directamente desde el terminal. |
| 8. La configuración administrada no se ha cargado correctamente | Pide al administrador que repare la fuente de configuración que falla. Usa claude doctor para investigar fallos al obtener la configuración administrada desde el servidor. Los fallos de consulta al registro tienen el comportamiento específico de la siguiente fila. |
| 9. Falla la consulta al registro de Windows | Afecta a Windows y WSL, incluso cuando WSL no usa la configuración del registro. Las causas incluyen la interoperabilidad desactivada, Windows en un idioma distinto del inglés o un contenedor sobre un kernel WSL2. Restablece la interoperabilidad solo si está permitido; de lo contrario, realiza tú la limpieza prevista. |
Después de un cambio autorizado, vuelve a comprobar el aviso de inicio. Si un hook de Windows se comporta de forma inesperada, revisa las comprobaciones del binario activo y los hooks de Windows antes de cambiar la política de permisos.
Audita el entorno de lanzamiento y aplica la política del equipo
Audita tanto los archivos de configuración como el entorno del proceso que inicia Claude Code. Una búsqueda sin resultados en el repositorio no permite saber qué variables inyecta un servicio de CI alojado.
Busca asignaciones persistentes y recházalas en CI
Busca en el repositorio y en los perfiles habituales del shell sin imprimir el contenido de los archivos. Este ejemplo de Bash requiere ripgrep y muestra los nombres de los archivos que contienen coincidencias:
audit_paths=(.)
for audit_path in \
"$HOME/.bashrc" "$HOME/.bash_profile" "$HOME/.profile" \
"$HOME/.zshrc" "$HOME/.zprofile" "$HOME/.zshenv"
do
if [[ -f "$audit_path" ]]; then
audit_paths+=("$audit_path")
fi
done
rg -l --hidden --no-ignore -F \
-g '!.git/**' -g '!node_modules/**' \
'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' \
"${audit_paths[@]}"Revisa las coincidencias antes de cambiarlas; que un documento mencione la variable no significa que la exporte. Amplía la búsqueda a los archivos cargados desde los perfiles, los scripts de lanzamiento, las definiciones de contenedores y los archivos de entorno.
Comprueba también las variables de CI en los ámbitos de organización, repositorio, entorno y trabajo. Revisa el entorno del servicio del runner y cualquier paso que modifique variables antes de iniciar Claude Code. No vuelques todo el entorno en los registros.
Coloca esta comprobación de Bash justo antes de invocar Claude Code en un lanzador de CI controlado:
if [[ -n "${CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS+x}" ]]; then
printf '%s\n' 'Refusing Claude Code launch: critical-path override variable is set.' >&2
exit 1
fiLa comprobación rechaza cualquier presencia de la variable, incluso si está vacía o vale 0. Esta política conservadora del lanzador no implica que todos los valores activen la función. Solo protege las rutas de ejecución que realmente pasan por la comprobación.
Desactiva el modo de omisión de permisos mediante la configuración administrada
Bloquea este modo si tu equipo no lo necesita. La variable requiere ese modo, por lo que bloquearlo elimina una condición necesaria para que funcione. Un bloque env de la configuración administrada no puede neutralizar esta variable que solo se lee al iniciar.
Incorpora este control a la configuración administrada activa de la organización:
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}Si distribuyes la configuración mediante un archivo, usa estas ubicaciones:
- macOS:
/Library/Application Support/ClaudeCode/managed-settings.json - Linux y WSL:
/etc/claude-code/managed-settings.json - Windows:
C:\Program Files\ClaudeCode\managed-settings.json
Reinicia Claude Code y consulta /status. Confirma que Setting sources indique la fuente administrada prevista. Un nuevo intento de entrar en bypassPermissions debería rechazarse.
Comprueba la fuente seleccionada antes del despliegue: otra fuente administrada de mayor prioridad puede sustituir al archivo distribuido. Protege la política mediante la administración de los dispositivos. Una persona con acceso de administrador local puede editar una política basada en archivos.
¿Qué protege mejor: las reglas deny o el sandbox?
Usa el aislamiento del sistema operativo para delimitar el acceso al sistema de archivos y las reglas de permisos para controlar llamadas concretas a herramientas. La confirmación para rutas críticas es una comprobación adicional, no una protección completa del sistema de archivos.
Conserva las reglas deny útiles. Sin embargo, las reglas de Bash comparan el texto del comando. Bash(rm *) no cubre todas las formas de invocación ni otros programas que borren archivos. Revisa también los hooks y mods instalados, ya que las extensiones pueden influir en las decisiones sobre permisos.
En los sistemas macOS, Linux y WSL2 compatibles, incorpora estos ajustes del sandbox a la política administrada:
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false
}
}Esta configuración impide el inicio cuando el sandbox no está disponible y desactiva los reintentos fuera de él. Windows nativo no admite este sandbox, por lo que la política impediría el inicio en ese sistema.
Consulta /sandbox para revisar la configuración efectiva y las dependencias. Audita excludedCommands y las rutas con permiso de escritura. El modo estricto sigue admitiendo exclusiones, y los ajustes del usuario o --settings pueden ampliar algunas listas.
Los comandos ejecutados en el sandbox todavía pueden borrar datos del proyecto con permiso de escritura. El aislamiento integrado tampoco abarca todos los hooks, servidores MCP iniciados localmente o herramientas de archivos. Para trabajos desatendidos que necesiten ese alcance, aísla todo el proceso de Claude Code en un contenedor, una máquina virtual o un runtime de sandbox. No montes rutas valiosas del host con permiso de escritura y asegúrate de poder reemplazar la copia de trabajo.
