Permisos de Claude Code: qué cambia al usar bypass

¿Qué comprobaciones de los permisos de Claude Code desactiva esta opción?

--dangerously-skip-permissions y --permission-mode bypassPermissions activan el mismo modo. Claude puede modificar archivos, ejecutar comandos de shell y realizar otras llamadas a herramientas sin las pausas de aprobación habituales. Este modo también permite escribir en rutas protegidas. El primer inicio interactivo muestra una advertencia sobre la responsabilidad que asumes; si no la aceptas, Claude Code se cierra. Documentación de Anthropic sobre la omisión de permisos

Imagina que los permisos son un puesto de control y que el aislamiento son las paredes del taller. Quitar el control no levanta paredes. Ganas una sesión de trabajo sin interrupciones, pero pierdes la oportunidad de detectar una acción perjudicial antes de que se ejecute.

El trabajo cambia: en lugar de aprobar cada operación, primero defines el entorno y después revisas los resultados. Eso no garantiza que el código sea correcto ni neutraliza las instrucciones maliciosas.

¿Qué controles siguen activos?

La palabra «skip» no significa que desaparezcan todos los controles. Estas diferencias explican por qué una ejecución que debía avanzar sin supervisión puede detenerse o rechazar una acción:

En la última fila, la opción exacta es permissions.blockReadsOutsideWorkingDirectories: true. Los comandos de Bash reconocidos como operaciones de lectura de archivos todavía pueden pedir confirmación fuera de los directorios permitidos; los bloqueos impuestos por el sandbox funcionan de otra manera. En una ejecución no interactiva con -p y bypass, las llamadas que aún necesitarían confirmación se deniegan. Acciones que ningún modo aprueba automáticamente, opción de lectura fuera de los directorios permitidos

Los hooks de PreToolUse que bloquean acciones también siguen interviniendo en la aprobación de herramientas. Hay una excepción especial para EndConversation: las reglas de denegación y de solicitud de aprobación no lo restringen mientras quede otra herramienta disponible. Los mods instalados pueden anular algunas decisiones de permisos que no procedan de una política administrada, por lo que los controles obligatorios de un equipo deben establecerse en esa política. Los administradores pueden prohibir el modo bypass con "permissions": {"disableBypassPermissionsMode": "disable"}. Una sesión iniciada con --restricted también lo rechaza. Prioridad de hooks y reglas, opción para deshabilitar bypass

El modo bypass permite escribir en rutas protegidas

No des por hecho que modificar .git o .claude seguirá exigiendo confirmación. El modo bypass permite escribir en rutas protegidas. Esta protección es distinta de las comprobaciones de borrado de directorios críticos descritas antes.

La lista de rutas protegidas de Anthropic incluye:

Dentro de .claude hay excepciones acotadas: los worktrees del propio Claude, los archivos del plan actual, el espacio temporal de las sesiones en segundo plano y ciertos archivos de memoria en Markdown. En las sesiones habituales de los modos Manual y acceptEdits, las escrituras protegidas requieren confirmación; el modo automático las remite a su clasificador. Una regla de autorización en un archivo de configuración no puede aprobarlas de antemano. Rutas protegidas y excepciones

Cuatro formas más seguras de reducir las interrupciones

Elige el control que resuelva la interrupción que tienes. La mayoría de los desarrolladores necesita ajustar su política de aprobación antes de recurrir al modo bypass.

Usa el modo automático para el trabajo de programación habitual

Inicia una sesión con claude --permission-mode auto. Un clasificador, es decir, un modelo independiente que revisa las acciones propuestas, se encarga de las decisiones de aprobación habituales. Para establecerlo como modo predeterminado en la terminal, incorpora "permissions": {"defaultMode": "auto"} a ~/.claude/settings.json.

Añadir ese valor a .claude/settings.json o .claude/settings.local.json no lo activa. El modo automático también depende de los modelos compatibles y de la configuración de la organización, y las reglas explícitas que exigen aprobación siguen generando solicitudes. Reduce las interrupciones, pero no garantiza la seguridad. Configuración del modo predeterminado, requisitos del modo automático

Nuestra guía del modo automático de Claude Code explica cuándo encaja ese modelo de revisión en tu forma de trabajar.

Autoriza las tareas habituales y bloquea acciones concretas

Usa permissions.allow para los comandos que hayas revisado y permissions.deny para las operaciones que quieras bloquear. Claude Code evalúa primero las denegaciones, después las solicitudes de aprobación y, por último, las autorizaciones. Una autorización amplia no puede anular una denegación que coincida con la acción. Reglas de permisos

En un repositorio de confianza, el siguiente ejemplo combina autorizaciones específicas con un hook de bloqueo. Incorpóralo a .claude/settings.json sin eliminar las claves que ya existan. El ejemplo inicia deliberadamente las sesiones de terminal en modo Manual para que las autorizaciones de la lista sean las que determinen qué se aprueba. Antes de autorizar los scripts de pruebas y lint del proyecto, comprueba qué ejecutan.

{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)", "Read(./.env.*)"]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "if": "Bash(rm *)",
        "command": "echo 'Use the approved cleanup task instead.' >&2; exit 2"
      }]
    }]
  }
}

Usa .claude/settings.local.json para los ajustes personales de ese proyecto; si creas el archivo por tu cuenta, añádelo a .gitignore. Abre /permissions para consultar las reglas activas y los archivos de los que proceden. Ámbito de la configuración

Estos patrones no aíslan el sistema de archivos ni la red. Una forma alternativa de escribir un comando puede eludir un patrón de Bash, y un script cualquiera puede leer archivos indirectamente pese a las reglas de denegación de las herramientas de archivos. Mantén los secretos fuera del entorno y aplica restricciones mediante un sandbox cuando el acceso deba ser imposible. Límites de las reglas de Bash, límites de las reglas de archivos

Empieza con el modo de planificación antes de un cambio amplio

Inicia la sesión con claude --permission-mode plan o añade "permissions": {"defaultMode": "plan"} a la configuración del proyecto. Claude explora y propone el trabajo antes de que se aprueben cambios en el código fuente. La opción de nivel superior "useAutoModeDuringPlan": false desactiva la aprobación de comandos de planificación por parte del clasificador; así, los comandos que no formen parte del conjunto integrado de solo lectura necesitan tu aprobación. Configuración del modo de planificación

Abre una sesión de planificación nueva sin opciones que habiliten bypass. En una sesión interactiva de terminal donde bypass está disponible, el modo de planificación no aplica sus bloqueos habituales de edición y comandos. Esto incluye la disponibilidad que añade --allow-dangerously-skip-permissions, una opción que permite seleccionar bypass más adelante sin activarlo de inmediato. Modo de planificación y disponibilidad de bypass

Usa hooks para bloquear comandos específicos

El manejador hooks.PreToolUse del ejemplo utiliza matcher: "Bash", type: "command" e if: "Bash(rm *)". Cuando se cumple esa condición, el comando de shell muestra el motivo y termina con el código 2, lo que bloquea la llamada a la herramienta. No necesita un script aparte. El comando de shell es un pequeño ejemplo nuestro que usa los campos de hooks y el código de salida de bloqueo documentados por Anthropic. Configuración de hooks, códigos de salida que bloquean

Esto bloquea las llamadas a rm que coinciden con el patrón, pero no todas las formas posibles de borrar un archivo. Un equipo podría sustituirlo por un validador revisado para sus propios comandos de despliegue o limpieza. Acota las comprobaciones para que sean fáciles de entender y probar. Nuestra página sobre hooks de Claude Code explica su configuración y depuración.

¿En qué entornos permite Anthropic usar bypass?

La tabla de configuraciones habituales de Anthropic exige un contenedor, una máquina virtual o un entorno de ejecución aislado mediante sandbox, con un usuario sin privilegios de root en Linux y macOS. La sección sobre bypass describe entornos aislados que no pueden dañar el sistema anfitrión y menciona expresamente los entornos sin acceso a internet. La guía de devcontainers ofrece una configuración conectada, con acceso de salida restringido a los servicios que Claude necesita. Considera la red sin restricciones como una exposición adicional. Aislamiento requerido, restricciones de red del devcontainer

En Linux y macOS, normalmente se rechaza el inicio de bypass como root o mediante sudo. La documentación indica una excepción automática dentro de un sandbox reconocido; el procedimiento documentado con devcontainer utiliza una cuenta sin privilegios de root. No resuelvas un error de root debilitando ese límite.

Configuración rápida con el devcontainer de referencia

Usa una copia de trabajo desechable de un repositorio de confianza. Con Docker, VS Code y la extensión Dev Containers instalados, empieza por el proyecto de referencia de Anthropic:

git clone https://github.com/anthropics/claude-code.git claude-code-isolated
code claude-code-isolated

1. En VS Code, ejecuta Dev Containers: Reopen in Container. La configuración de referencia combina la CLI, volúmenes persistentes y un firewall de salida. Comprueba que remoteUser indique una cuenta sin privilegios de root.
2. En la terminal del contenedor, ejecuta id -u y confirma que el resultado no sea 0. Ejecuta claude para iniciar sesión y luego sal de esa sesión.
3. En esa misma terminal del contenedor, ejecuta claude -p "Inspect this repository and summarize its structure. Do not change files." --dangerously-skip-permissions.
4. Para tu propio proyecto, copia el directorio .devcontainer/ de referencia en una copia de trabajo desechable y adapta el Dockerfile a sus herramientas de desarrollo. Revisa el diff del espacio de trabajo después de cada tarea.

Estos pasos siguen el procedimiento de Anthropic para el contenedor de referencia. La referencia es un ejemplo funcional, no una imagen base con mantenimiento. Conserva sus restricciones de salida o aplica controles de red equivalentes.

El espacio de trabajo montado sigue admitiendo escrituras desde dentro del contenedor, y esos cambios llegan al sistema anfitrión. Evita montar ~/.ssh, archivos de credenciales de la nube o directorios ajenos al trabajo. Un proyecto malicioso todavía puede filtrar cualquier dato accesible dentro del contenedor, incluidas las credenciales de Claude. Usa repositorios de confianza y supervisa el trabajo. Límites del devcontainer

Las sesiones en la nube ignoran bypass como modo predeterminado

Las sesiones en la nube ignoran sin avisar los valores defaultMode: "bypassPermissions" y defaultMode: "dontAsk" de los archivos de configuración. Se inician en el modo que muestra el selector de la nube. Un ajuste JSON guardado en el repositorio no puede forzar una sesión en la nube a usar bypass. Comportamiento de los modos en la nube

Tu archivo local ~/.claude/settings.json no se traslada a una sesión en la nube alojada por Anthropic. La configuración del repositorio también tiene sus límites: las sesiones que abarcan varios repositorios no cargan las reglas de permisos ni los hooks de cada uno. Revisa la política que realmente aplica el entorno en la nube, en lugar de asumir que heredó la configuración de tu terminal. Configuración en sesiones en la nube

Elige el modo según el trabajo

El cambio más útil suele ser eliminar las aprobaciones repetitivas de un proceso que ya utilizas. Estas son opciones prácticas, en el orden en que yo empezaría:

Para el caso de CI, claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" es el punto de partida documentado por Anthropic. Deniega las operaciones que, de otro modo, pedirían confirmación. Configuraciones habituales

Complementa el modo que elijas con nuestras buenas prácticas de Claude Code. Los permisos regulan la ejecución; la verificación determina si vale la pena conservar el resultado.

Dos herramientas útiles que un equipo podría crear

Un verificador de la configuración de permisos es la oportunidad más prometedora. DataForSEO estima 720 búsquedas mensuales en Estados Unidos de «claude code permissions». Eso apunta a una dificultad para encontrar información, no a una intención de compra demostrada. Un equipo de plataforma para desarrolladores podría crear un pequeño verificador que explique el ámbito de cada ajuste, señale los valores de defaultMode que se ignoran y muestre de antemano el alcance de las reglas amplias de comandos antes de incorporar a otros compañeros. Su primer resultado útil sería un informe con cambios sugeridos. La dificultad estaría en mantenerlo al día conforme cambie el comportamiento de la configuración de Claude Code.

Una herramienta para iniciar ejecuciones desechables podría servir a equipos con tareas recurrentes sin supervisión. La misma consulta de demanda estima 260 búsquedas mensuales en Estados Unidos de «claude code docker». Un MVP podría validar una plantilla de contenedor revisada, los montajes permitidos, la ejecución sin privilegios de root y la política de conexiones de salida, y después recopilar el diff y los registros para un responsable de mantenimiento. Su valor estaría en ofrecer una configuración consistente. Su límite: no puede convertir en seguro el código de un repositorio que no sea de confianza ni garantizar el aislamiento por el simple hecho de usar Docker.

Ambas son oportunidades para crear herramientas internas que conviene validar con usuarios reales. Ninguna exige convertir bypass en el modo predeterminado de las máquinas de los desarrolladores.

Para empezar el lunes: elige un proceso repetitivo, revisa los comandos que ejecuta en realidad y configura la política de aprobación mínima que permita completarlo. Pasa a un contenedor desechable solo cuando la tarea necesite una ejecución sin supervisión que vaya más allá de esa política.

Si tu equipo necesita que alguien construya y mantenga ese proceso, podemos ayudarte con sistemas de IA en producción.