SpyBara
Go Premium

permission-modes.md 2026-10-01 23:59 UTC to 2026-10-02 10:01 UTC

This page contains 148 additions and 147 deletions.

2026
Thu 1 23:59 Fri 2 10:01

Elegir un modo de permisos

Controle si Claude solicita aprobación antes de actuar. Cambie de modo de permisos con Mayús+Tab en la CLI, el indicador de modo en VS Code, o el selector de modo en Desktop.

Un modo de permisos establece qué acciones puede realizar Claude en una sesión sin pedirle permiso primero. En modo Manual, Claude Code se detiene y le solicita aprobación antes de la mayoría de acciones que editan archivos, ejecutan comandos de shell o alcanzan la red. En modo automático, un segundo modelo, el clasificador, revisa acciones en su lugar; cómo el clasificador evalúa acciones enumera qué acciones revisa y cuáles se omiten.

Con Claude Code v2.1.283 o posterior, el modo automático es el modo de permisos inicial integrado para sesiones de terminal interactivo y VS Code. En versiones anteriores, es el modo de permisos inicial integrado solo en planes Pro, Max y Team. Qué modo inicia una sesión cubre las superficies y configuraciones que cambian el modo de permisos inicial. También puede cambiar el modo de permisos de una sesión en ejecución en cualquier momento.

Modos disponibles

Cada modo hace un compromiso diferente entre conveniencia y supervisión. La tabla a continuación muestra qué puede hacer Claude sin un aviso de permiso en cada modo. El modo manual aparece bajo su valor de configuración, default.

Modo Qué se ejecuta sin preguntar Mejor para
default Solo lecturas Revisar cada acción usted mismo, trabajo sensible
acceptEdits Lecturas, ediciones de archivos y comandos comunes del sistema de archivos (mkdir, touch, mv, cp, etc.) Iterar sobre código que está revisando
plan Lecturas, más comandos aprobados por clasificador cuando modo automático está disponible Explorar una base de código antes de cambiarla
auto Todo, con verificaciones de seguridad en segundo plano Tareas largas, reducir fatiga de avisos
dontAsk Lecturas y herramientas preaprobadas; cualquier cosa que generaría un aviso se deniega CI bloqueado y scripts
bypassPermissions Todo Solo contenedores aislados y máquinas virtuales

El modo que revisa cada acción se llama Manual en la CLI, en claude --help, en las extensiones de VS Code y JetBrains, y en la aplicación de escritorio. Su valor de configuración es default, que es lo que usan los hooks e integraciones de SDK. La CLI acepta manual como un alias dondequiera que escriba el valor, por ejemplo claude --permission-mode manual o "defaultMode": "manual". La etiqueta Manual y el alias manual requieren Claude Code v2.1.200 o posterior. La etiqueta de la aplicación de escritorio no depende de su versión de CLI.

Las escrituras en rutas protegidas nunca se aprueban automáticamente excepto en modo bypassPermissions y en sesiones de modo plan donde los permisos de omisión están disponibles, lo que significa sesiones de terminal interactivas iniciadas de una manera que pone bypassPermissions en el ciclo de modo.

Los modos establecen la línea base. Superponga reglas de permiso encima para preaprobación o bloqueo de herramientas específicas. Las reglas de denegación bloquean en cada modo, incluido bypassPermissions. Las reglas de denegación y pregunta no se aplican a EndConversation siempre que Claude aún tenga al menos otra herramienta que pueda llamar. Las reglas de permiso no tienen efecto en bypassPermissions.

Acciones que ningún modo aprueba automáticamente

Claude Code no aprueba automáticamente lo siguiente en ningún modo, incluido bypassPermissions. Cada viñeta enlaza a la sección que dice qué sucede en su lugar en cada modo:

  • Herramientas coincidentes por una regla de pregunta explícita

  • Herramientas de conector que su organización estableció en ask, en sesiones donde esa configuración llega a Claude Code

  • Herramientas que requieren interacción del usuario: la herramienta integrada AskUserQuestion y herramientas MCP marcadas requiresUserInteraction

  • Eliminaciones de rm y rmdir dirigidas a una ruta crítica, que ninguna regla de permiso o hook PreToolUse "allow" aprueba

  • Las salvaguardas de mensajería entre sesiones

  • Lecturas fuera de los directorios de trabajo mientras permissions.blockReadsOutsideWorkingDirectories está activado: los comandos Bash reconocidos de lectura de archivos generan avisos incluso en modo automático y modo bypassPermissions, y también lo hace cualquier reintento sin sandbox que necesita aprobación para ejecutarse fuera del sandbox. Requiere Claude Code v2.1.257 o posterior.

    Un comando que el analizador de shell no puede rastrear, como uno que cambia de directorio más de una vez o ejecuta un subshell, genera avisos de la misma manera incluso cuando no nombra ninguna ruta externa. Este aviso no se aplica cuando el comando se ejecuta en el sandbox y el sandbox aplica el bloqueo.

Configuraciones comunes

Los modos de permisos deciden si Claude solicita antes de una acción, y el sandbox Bash y los límites de aislamiento externos deciden qué puede alcanzar una acción una vez que se ejecuta. Cada fila a continuación empareja un objetivo con las banderas o configuraciones que lo logran y el aislamiento que necesita, como punto de partida. Modos disponibles enumera qué se ejecuta sin un aviso en cada modo.

Usted quiere Comience con Aislamiento necesario Notas
Revisar cada acción usted mismo Modo Manual: claude --permission-mode default Ninguno Trabajo sensible, código desconocido
Iterar localmente con menos avisos, sin un clasificador Modo Manual más el sandbox Bash en modo de permitir automático: claude --permission-mode default, luego ejecute /sandbox y seleccione permitir automático El sandbox Bash integrado, en macOS, Linux y WSL2 Las reglas de denegación aún se aplican, y las reglas de solicitud que nombran un comando, como Bash(git push *), aún solicitan. Para activar el sandbox desde un archivo de configuración en su lugar, establezca sandbox.enabled en true
Explorar antes de cambiar nada claude --permission-mode plan Ninguno Claude Code bloquea ediciones hasta que apruebe un plan
Trabajar sin intervención en modo automático claude --permission-mode auto, el modo de permisos inicial integrado con v2.1.283 o posterior Ninguno; un sandbox o contenedor agrega defensa en profundidad Requiere un modelo compatible, y su organización puede desactivar modo automático
Ejecutar en CI con una lista de permitidos exacta claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" Ninguno más allá de lo que proporciona su ejecutor de CI Cloud sessions ignora dontAsk de archivos de configuración
Ejecutar completamente desatendido dentro de un contenedor claude -p "<prompt>" --dangerously-skip-permissions Requerido: un contenedor, máquina virtual o el tiempo de ejecución del sandbox; en Linux y macOS, ejecútelo como un usuario no root Cloud sessions ignora este modo de archivos de configuración. En esta ejecución -p, las pocas llamadas que aún solicitarían se deniegan en su lugar

El sandbox Bash y el modo automático funcionan independientemente y se combinan, con las excepciones enumeradas en Modos de sandbox. Para la interacción completa, consulte Cómo el sandboxing se relaciona con permisos y modos de permisos y Cómo el aislamiento se relaciona con modos de permisos.

Qué modo inicia una sesión

Cuando inicia una nueva sesión en una terminal, Claude Code toma el modo de permisos del primero de estos que se aplique:

  1. La bandera --permission-mode o --dangerously-skip-permissions

  2. permissions.defaultMode en un archivo de configuración

    Si establece "auto" en .claude/settings.json o .claude/settings.local.json, el valor no entra en vigor, y Claude Code luego usa el valor predeterminado integrado en lugar de un defaultMode de ~/.claude/settings.json. Si establece "bypassPermissions" en esos dos archivos, tampoco entra en vigor, y la sesión comienza en modo Manual. Los otros valores se aplican desde cualquier archivo de configuración.

  3. El valor predeterminado integrado

Las conversaciones que inicia la extensión de VS Code siguen la lista propia de la extensión en Cambiar modos de permisos. Para el modo de permisos en el que Claude Code inicia una sesión reanudada, consulte modo de permisos al reanudar.

El valor predeterminado integrado auto requiere Claude Code v2.1.228 o posterior en macOS, Linux y WSL, y v2.1.233 o posterior en Windows nativo. En versiones anteriores, el valor predeterminado integrado es Manual.

El valor predeterminado integrado depende de cómo ejecute Claude Code. La primera fila que coincida con su sesión se aplica. La tabla cubre sesiones que inicia en una terminal o a través de la extensión de VS Code; para la aplicación de escritorio y claude.ai, consulte las pestañas Desktop y Web en Cambiar modos de permisos.

Cómo ejecuta Claude Code Modo de permisos inicial integrado
Cualquier archivo de configuración establece disableAutoMode en "disable" default
claude -p o el Agent SDK default en sesiones que obtienen banderas de características. En sesiones que no lo hacen, como en un proveedor de terceros o con telemetría desactivada, auto con Claude Code v2.1.285 o posterior y default en versiones anteriores. Una sesión en una organización cuya política retiene el valor predeterminado auto comienza en default en su lugar
En una terminal o a través de la extensión de VS Code auto con Claude Code v2.1.283 o posterior; en versiones anteriores, auto en planes Pro, Max o Team en sesiones que obtienen banderas de características, y default en caso contrario

En su primera sesión después de una instalación o actualización, Claude Code puede elegir el modo de permisos inicial antes de que lleguen sus banderas de características. Esa sesión puede iniciarse en un modo de permisos diferente al que proporciona la tabla, y su siguiente sesión coincide con la tabla.

Cuando la bandera, un archivo de configuración o el valor predeterminado integrado selecciona auto pero el modo automático no está disponible para la sesión, Claude Code inicia la sesión en Manual en su lugar. El modo automático no está disponible cuando la sesión no cumple con los requisitos de disponibilidad, como un archivo de configuración desactivándolo o un modelo que no lo admite, o cuando Anthropic lo ha desactivado temporalmente del lado del servidor.

La primera vez que el valor predeterminado integrado inicia una de sus sesiones en modo automático, Claude Code muestra un aviso que enlaza a esta página:

  • En una terminal, una vez, en la parte superior de la sesión
  • En la extensión de VS Code, como una tarjeta en la pantalla de nueva conversación que permanece hasta que la descarte

Si su ~/.claude/settings.json establece un defaultMode distinto de auto y ningún otro archivo de configuración establece uno, sus sesiones siguen iniciándose en ese modo. En planes Pro, Max y Team, y en sesiones que no obtienen banderas de características, Claude Code pregunta una vez, en la terminal o en la extensión de VS Code, si desea cambiar la configuración a modo automático. Si rechaza, su configuración permanece como está.

Comience en un modo de permisos diferente

Puede establecer el modo de permisos inicial para una sesión, o como predeterminado para cada sesión en una máquina, proyecto u organización. Cuando más de un archivo de configuración establece permissions.defaultMode, precedencia de configuración decide, por lo que un valor de proyecto o administrado supera ~/.claude/settings.json. Para cambiar el modo de permisos de una sesión que ya se está ejecutando, consulte Cambiar modos de permisos.

Para establecer el modo de permisos inicial para Haga esto
Una sesión que está a punto de iniciar Pase el modo de permisos como una bandera, por ejemplo claude --permission-mode default
Cada sesión de terminal que inicia en esta máquina Establezca permissions.defaultMode en ~/.claude/settings.json. Para lo que lee la extensión de VS Code, consulte Cambiar modos de permisos
Cada sesión de terminal que inicia en un proyecto Establezca permissions.defaultMode en .claude/settings.json del proyecto. Las sesiones que inicia en una terminal respetan cada valor excepto auto y bypassPermissions; las sesiones que inicia la extensión de VS Code no leen configuración de proyecto para el modo de permisos inicial
Cada sesión de terminal en su organización Establezca permissions.defaultMode en configuración administrada. Las sesiones de terminal comienzan en ese modo y las personas aún pueden cambiar a modo automático; para lo que lee la extensión de VS Code, consulte Cambiar modos de permisos. Para eliminar modo automático para que nadie pueda seleccionarlo, establezca permissions.disableAutoMode en "disable" en su lugar

Este ejemplo hace que cada sesión de terminal en su máquina comience en modo Manual, cuyo valor de configuración es default. Guárdelo en ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

La siguiente sesión que inicia muestra ⏸ manual mode on en la barra de estado.

Cambiar modos de permisos

Cada interfaz tiene su propio control para cambiar modos de permisos durante una sesión y su propia forma de elegir el modo de permisos que inician las nuevas sesiones. Seleccione su interfaz para ver sus controles.

Durante una sesión: presione Shift+Tab para ciclar modos de permisos. Desde auto, el primer presionamiento cambia a default, y el ciclo luego ejecuta default → acceptEdits → plan → de vuelta a default. Los modos opcionales, descritos a continuación, se insertan después de plan. La barra de estado muestra el modo activo como un ⏸ manual mode on gris para default, o como ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on, o ⏵⏵ bypass permissions on.

No todos los modos están en el ciclo predeterminado:

  • auto: aparece cuando modo automático está disponible; cambiar a él cambia modos de permisos sin un aviso de confirmación
  • bypassPermissions: aparece después de que inicia con --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions o permissions.defaultMode: "bypassPermissions" en configuración de usuario, --settings o administrada. La variante --allow- agrega el modo de permisos al ciclo sin activarlo
  • dontAsk: nunca aparece en el ciclo; establézcalo con --permission-mode dontAsk

Los modos opcionales habilitados se insertan después de plan, con bypassPermissions primero y auto último. Si tiene ambos habilitados, ciclará a través de bypassPermissions en el camino a auto.

Desde un aviso de permisos Bash: en los modos de permisos Manual y acceptEdits, cuando modo automático está disponible, Claude Code agrega Sí, y cambiar a modo automático al aviso de permisos de un comando Bash. Selecciónelo para aprobar el comando y cambiar la sesión a modo automático. Los avisos de la herramienta PowerShell no ofrecen la opción. Requiere Claude Code v2.1.247 o posterior.

Claude Code no agrega la opción a avisos forzados por una de sus reglas ask o por un hook, porque el modo automático aún le muestra esos avisos, por lo que cambiar no los eliminaría.

Al inicio: pase el modo de permisos como una bandera.

claude --permission-mode plan

Como predeterminado: establezca permissions.defaultMode en el alcance que desee, como se describe en Comience en un modo de permisos diferente.

La misma bandera --permission-mode funciona con -p para ejecuciones no interactivas.

Aprobar automáticamente ediciones de archivos con modo acceptEdits

El modo acceptEdits permite que Claude cree y edite archivos en su directorio de trabajo sin solicitar. La barra de estado muestra ⏵⏵ accept edits on mientras este modo está activo.

Además de ediciones de archivos, el modo acceptEdits aprueba automáticamente comandos Bash comunes del sistema de archivos: mkdir, touch, rm, rmdir, mv, cp y sed. Estos comandos también se aprueban automáticamente cuando van precedidos de variables de entorno seguras como LANG=C o NO_COLOR=1, o envoltorios de procesos como timeout, nice o nohup. Al igual que las ediciones de archivos, la aprobación automática se aplica solo a rutas dentro de su directorio de trabajo o additionalDirectories.

Cada ruta también pasa por la verificación de enlaces simbólicos, por lo que una escritura que se resuelve fuera de ese alcance tampoco se aprueba automáticamente. Las rutas fuera de ese alcance, las escrituras en rutas protegidas, las eliminaciones rm y rmdir dirigidas a una ruta crítica y todos los demás comandos Bash excepto el conjunto integrado de solo lectura aún solicitan.

Cuando la herramienta PowerShell está habilitada, el modo acceptEdits también aprueba automáticamente Set-Content, Add-Content, Clear-Content y Remove-Item en rutas dentro del alcance, junto con sus alias comunes. Se aplican las mismas reglas de alcance y ruta protegida, y Remove-Item obtiene su propia verificación. Un argumento posicional que contiene un carácter de comilla, como el apóstrofo en Set-Content .\notes.txt "It's done", aún solicita incluso en rutas dentro del alcance, porque Claude Code no puede validar estáticamente un argumento cuyas lecturas entrecomilladas y sin entrecomillar difieren. Pase el contenido a través de un parámetro nombrado como -Value para evitar el aviso.

Utilice acceptEdits cuando desee revisar cambios en su editor o mediante git diff después del hecho en lugar de aprobar cada edición en línea.

Presione Shift+Tab una vez desde modo Manual para entrar en él, o comience directamente con él:

claude --permission-mode acceptEdits

Analice antes de editar con modo plan

El modo plan le indica a Claude que investigue y proponga cambios sin realizarlos. Claude lee archivos, ejecuta comandos de shell para explorar y escribe un plan, pero no edita su fuente. Excepto en sesiones interactivas de terminal con permisos de omisión disponibles, las ediciones permanecen bloqueadas hasta que apruebe el plan.

Lo que sucede con un comando de shell durante la planificación depende de la sesión, y se aplica el primero de estos casos que coincida:

Ingrese al modo plan presionando Shift+Tab o prefijando un único aviso con /plan. También puede comenzar en modo plan desde la CLI:

claude --permission-mode plan

Presione Shift+Tab nuevamente para salir del modo plan sin aprobar un plan.

Revise y apruebe un plan

Cuando el plan esté listo, Claude lo presenta y pregunta cómo proceder. Desde ese aviso puede elegir:

  • Sí, y usar modo automático: apruebe e inicie en modo automático. Si el modo automático no está disponible para su sesión, por ejemplo porque su organización lo desactivó, esta opción dice Sí, aceptar automáticamente ediciones. Si inició la sesión con permisos de omisión habilitados, la opción dice Sí, y cambiar a OMITIR PERMISOS (sin más avisos) para esta sesión en su lugar.
  • Sí, aprobar manualmente ediciones: apruebe y revise cada edición individualmente.
  • No, seguir planificando: permanezca en modo plan y dígale a Claude qué cambiar.

Aprobar un plan sale del modo plan y cambia la sesión al modo de permisos que describe cada opción de aprobación, por lo que Claude comienza a editar. Para planificar nuevamente, cicle de vuelta al modo plan con Shift+Tab, o prefije su próximo aviso con /plan.

Presione Ctrl+G para abrir el plan propuesto en su editor de texto predeterminado y edítelo directamente antes de que Claude continúe. Cuando showClearContextOnPlanAccept está habilitado, la lista gana una primera opción que aprueba el plan y borra el contexto de planificación.

Aprobar un plan también da a la sesión un título generado basado en el plan, a menos que ya haya nombrado la sesión.

Establezca el modo plan como predeterminado

Para hacer que el modo plan sea el predeterminado para las sesiones de terminal de un proyecto, establezca defaultMode en plan en .claude/settings.json, colocado como muestra el ejemplo bajo Comience en un modo de permisos diferente. Las conversaciones que inicia la extensión de VS Code no leen configuración de proyecto para el modo de permisos inicial. Allí, establezca claudeCode.initialPermissionMode en plan en su configuración de usuario de VS Code en su lugar.

Eliminar solicitudes de permiso con modo automático

El modo automático permite que Claude se ejecute sin solicitudes de permiso habituales. Un modelo clasificador separado revisa las acciones antes de que se ejecuten y bloquea cualquier cosa que escale más allá de tu solicitud, apunte a infraestructura no reconocida o parezca impulsada por contenido hostil que Claude leyó. Las reglas de preguntar explícitas aún fuerzan una solicitud de permiso.

Con Claude Code v2.1.283 o posterior, el modo automático es el modo de permisos de inicio integrado para sesiones interactivas de terminal y de VS Code en todos los planes y proveedores. En versiones anteriores, es el modo de permisos de inicio integrado solo en los planes Pro, Max y Team.

El clasificador también revisa cada mensaje que Claude envía a otro agente con SendMessage, ya sea texto sin formato o un mensaje estructurado de equipo de agentes, antes de que Claude Code lo entregue, tanto en modo automático como en modo plan mientras el clasificador revisa comandos; la revisión de envíos requiere Claude Code v2.1.222 o posterior.

De forma predeterminada, el clasificador no revisa las eliminaciones con rm y rmdir dirigidas a una ruta crítica, como rm -rf / o rm -rf ~. Rutas críticas explica lo que sucede con ellas en cada modo de permisos.

El modo automático también anima a Claude a seguir trabajando sin detenerse para hacer preguntas aclaratorias, aunque Claude aún pregunta cuando tu prompt o un skill depende explícitamente de ello. Para un comportamiento más autónomo en un modo que aún te pide confirmación, establece en su lugar el estilo de salida Proactive.

El modo automático está disponible solo cuando tu cuenta cumple todos estos requisitos:

  • Plan: Todos los planes.
  • Organización: en Team y Enterprise, el modo automático está disponible de forma predeterminada. Los administradores pueden desactivarlo para la organización estableciendo permissions.disableAutoMode en "disable" en la configuración administrada.
  • Modelo: en la API de Anthropic y Claude Platform on AWS, Claude Opus 4.6 o posterior, Sonnet 4.6 o posterior, o un modelo Fable. En Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry y sesiones del gateway de aplicaciones de Claude con sesión iniciada, solo Claude Sonnet 5 o posterior, Opus 4.7 o posterior y los modelos Fable. Los modelos más antiguos, incluidos Sonnet 4.5, Opus 4.5, Haiku y los modelos claude-3, no son compatibles en ningún proveedor.
  • Proveedor: disponible de forma predeterminada en la API de Anthropic, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry y sesiones del gateway de aplicaciones de Claude con sesión iniciada.

Si Claude Code informa que el modo automático no está disponible, primero verifica estos requisitos y si algún archivo de configuración establece disableAutoMode. Anthropic también puede haber desactivado el modo automático del lado del servidor, o el servidor puede haber rechazado el modo automático para tu cuenta. Una sesión que recibió cualquiera de estas respuestas mantiene el modo automático desactivado hasta que finaliza, así que inicia una nueva sesión más tarde.

Un mensaje distinto que nombra un modelo y dice que el modo automático "no puede determinar la seguridad" de una acción significa que falló una solicitud del clasificador. Ese fallo suele ser transitorio, pero en Amazon Bedrock puede repetirse hasta que tu cuenta pueda invocar el modelo nombrado. Consulta la referencia de errores para conocer las causas y qué hacer.

Si estableces defaultMode: "auto" en la configuración y una sesión de terminal comienza en modo Manual sin ningún error, probablemente el ajuste esté en .claude/settings.json o .claude/settings.local.json. auto no entra en vigor desde esos archivos. Muévelo a ~/.claude/settings.json. Para una conversación que inició la extensión de VS Code, revisa en su lugar la lista propia de la extensión en Cambiar modos de permisos.

Modo automático en Bedrock, Agent Platform o Foundry

En Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry y sesiones del gateway de aplicaciones de Claude con sesión iniciada, el modo automático está disponible de forma predeterminada. Cuando nada más establece un modo de permisos, también es el modo de permisos de inicio integrado, en las versiones que enumera la tabla de esa sección. Para elegir tú mismo el modo de permisos de inicio, establece permissions.defaultMode como describe Comenzar en un modo de permisos diferente, o selecciona un modo de permisos en el indicador de modo de la extensión de VS Code.

Solo Claude Sonnet 5 o posterior, Opus 4.7 o posterior y los modelos Fable son compatibles en estos proveedores. En cualquier otro modelo, la sesión comienza en Manual.

Para evitar que los desarrolladores usen el modo automático, establece disableAutoMode en "disable" en la configuración administrada. Esto elimina auto del ciclo de Shift+Tab, y una sesión iniciada con --permission-mode auto comienza en Manual. Una sesión que ya se ejecuta en modo automático lo abandona cuando el ajuste llega a esa sesión desde una fuente implementada por un administrador, y muestra auto mode disabled by settings. Antes de v2.1.251, una sesión en ejecución mantenía el modo automático hasta que finalizaba.

De v2.1.158 a v2.1.206, el modo automático estaba desactivado en estos proveedores hasta que establecieras CLAUDE_CODE_ENABLE_AUTO_MODE=1, y Claude Code ignoraba defaultMode: "auto" en estos proveedores a menos que la variable también estuviera establecida. La variable aún se acepta por compatibilidad y no tiene efecto a partir de v2.1.207.

Revisión del clasificador del lado del servidor

En modo automático, Claude Code puede pedirle al servidor que verifique las acciones que el orden de decisión envía a revisión, como parte de las solicitudes al modelo de la sesión, en lugar de enviar sus propias solicitudes al clasificador. Estas sesiones lo piden:

  • Una conexión directa a la API de Anthropic: en sesiones interactivas de terminal y en sesiones -p, de Agent SDK, de la extensión de VS Code y de la aplicación de escritorio, sea cual sea tu plan o tipo de cuenta, a medida que Anthropic lo implementa. En sesiones interactivas de terminal, esto requiere Claude Code v2.1.271 o posterior en los planes Pro, Max y Team, y v2.1.278 o posterior en los planes Enterprise y en cuentas de la API de Claude. En sesiones -p, de Agent SDK, de la extensión de VS Code y de la aplicación de escritorio, esto requiere Claude Code v2.1.281 o posterior. Desde v2.1.282, una sesión que no obtiene feature flags, por ejemplo porque desactivaste la telemetría, se lo pide al servidor de forma predeterminada en cualquier tipo de sesión.
  • Un proveedor de nube, o un gateway o proxy de LLM: en Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform y Microsoft Foundry, y siempre que apuntes ANTHROPIC_BASE_URL a un gateway o proxy de LLM, sea cual sea tu plan. Pedirlo de forma predeterminada requiere Claude Code v2.1.278 o posterior.
  • Una sesión del gateway de aplicaciones de Claude con sesión iniciada: requiere Claude Code v2.1.280 o posterior

Donde el servidor revisa las acciones, sus veredictos las deciden. Hay otros dos resultados posibles:

  • El servidor no revisa la sesión: una respuesta se completa sin resultados de revisión, o el servidor responde que no revisa esta sesión. Las causas más comunes son un gateway o proxy de LLM que descarta la solicitud de revisión o los resultados, y una plataforma, región o credencial que aún no tiene verificaciones del lado del servidor. Claude Code recurre a sus propias solicitudes al clasificador. Una vez que esa alternativa se mantiene durante el resto de la sesión, muestra un aviso sobre los cargos de las solicitudes al clasificador en las cuentas donde esas solicitudes se facturan.
  • El servidor no da un veredicto para una acción: Claude Code deniega la acción en lugar de ejecutarla sin revisar. En cualquier conexión, esto sucede cuando la respuesta termina antes de que lleguen los resultados de la revisión o cuando los resultados llegan en un formato que Claude Code no puede leer. Un gateway o proxy de LLM que corta las respuestas o reescribe los resultados puede causar cualquiera de los dos. En una conexión directa a la API de Anthropic, también sucede cuando la verificación del servidor falla para la acción, por ejemplo, al agotarse el tiempo de espera. El servidor no devolvió ningún veredicto de seguridad explica el mensaje de denegación, qué sucede cuando las denegaciones se repiten y qué hacer.

Para no pedírselo al servidor y usar siempre las propias solicitudes al clasificador de Claude Code, establece CLAUDE_CODE_AUTO_MODE_SERVER=0. En una conexión directa a la API de Anthropic, la variable requiere Claude Code v2.1.281 o posterior. Establecerla en 1 en ese caso activa la revisión del servidor en una sesión que aún no la tiene, a menos que también hayas establecido CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. Si estableces CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 y dejas CLAUDE_CODE_AUTO_MODE_SERVER sin establecer, Claude Code también deja de pedírselo al servidor, salvo en lo que describe Deshabilitar capacidades previas al lanzamiento.

Lo que el clasificador bloquea de forma predeterminada

El clasificador confía en tu directorio de trabajo y en los remotos que estaban configurados para él cuando comenzó la sesión. Un remoto agregado o reapuntado durante la sesión con git remote add o git remote set-url no es de confianza, y todo lo demás se trata como externo hasta que configures infraestructura de confianza. Antes de v2.1.200, los remotos agregados a mitad de sesión también eran de confianza.

Bloqueado de forma predeterminada:

  • Descargar y ejecutar código, como curl | bash
  • Enviar datos sensibles a endpoints externos
  • Implementaciones y migraciones de producción
  • Eliminación masiva en almacenamiento en la nube
  • Otorgar permisos de IAM o de repositorio
  • Modificar infraestructura compartida
  • Destruir de forma irreversible archivos que existían antes de la sesión
  • Push forzado
  • Hacer commit o push de un cambio que, al ejecutarse, enviaría secretos o datos sensibles fuera del repositorio, o ampliaría lo que expone una implementación. Esto cubre un workflow de CI o una configuración de implementación que pasa un secreto a un destino que aún no lo recibe, un script o paso de configuración que lee un almacén de secretos y envía los datos hacia fuera, y un cambio de configuración que amplía lo que publica una implementación, como un ajuste de registro, visibilidad, artefacto o sourcemap. La verificación se aplica en cualquier rama, se aplica incluso cuando el repositorio es público y se activa cuando se hace commit o push del cambio, independientemente de si ese commit o push desencadena el pipeline; para superarla hay que nombrar el efecto de la ejecución, no solo el commit o el push. Antes de v2.1.211, esta verificación se limitaba en cambio a la rama predeterminada: un push allí se bloqueaba cuando llevaba contenido sensible, cambios ocultos o mal descritos respecto de lo que pediste, contenido traído desde fuera del repositorio, o cuando eludía una revisión que pediste
  • git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop o git stash clear, que el clasificador presume que descartarían cambios sin confirmar
  • git commit --amend cuando el commit en HEAD no se creó en esta sesión
  • Desde v2.1.198, git commit --amend cuando ya se hizo push del commit en HEAD. Una reescritura solo del mensaje no se bloquea: --amend -m sin nada recién preparado, en un commit que Claude creó durante esta sesión
  • terraform destroy, pulumi destroy, cdk destroy o terragrunt destroy, y aplicar un plan que destruye recursos
  • Escribir en un administrador de secretos, o cambiar registros DNS o certificados TLS
  • Fusionar un pull request que ningún humano ha aprobado, aprobar el propio pull request de Claude o deshabilitar verificaciones de CI
  • Publicar un comentario que en sí mismo es un comando para una automatización, como atlantis apply o el /deploy o /merge de un bot
  • Activar, desactivar, escalonar o eliminar un feature flag de producción
  • Aplicar cambios de infraestructura a un alcance de IaC protegido, o drenar y eliminar nodos de un clúster
  • Escrituras en un clúster de cómputo compartido que van más allá del recurso que nombraste, como un selector de etiquetas o --all que abarca trabajos de otros usuarios
  • Crear recursos de Kubernetes que se ejecutan en cada nodo o interceptan el tráfico del clúster, como DaemonSets y webhooks de admisión
  • Shells interactivos o reenvíos de puertos hacia un destino remoto sensible
  • Abrir un túnel o un shell inverso que hace que un servicio local sea accesible desde internet público
  • Imprimir una credencial o un token vigente en la transcripción o en un archivo
  • Acceder a una ubicación listada como ubicación de datos sensibles en tu entorno, o copiar datos desde una. A partir de v2.1.198, esto también bloquea enviar datos desde una de ellas a una audiencia que la entrada excluye
  • Desviar la instalación de un paquete de tu registro de paquetes interno hacia un registro público. A partir de v2.1.198, esto también se aplica cuando le has dicho a Claude en la conversación que existe un registro interno o un mirror, no solo cuando hay uno listado en tu entorno
  • Ejecutar un comando con un flag que desactiva una protección de seguridad, como --insecure
  • Lanzar un bucle de agente autónomo que se ejecuta sin aprobación humana ni sandbox, como uno iniciado con --dangerously-skip-permissions o --no-sandbox. A partir de v2.1.198, esto también cubre ejecutar un agente de terceros o un arnés de evaluación con el aislamiento y la aprobación por acción deshabilitados, como un ejecutor iniciado con --yes-always
  • Acciones del navegador de Claude in Chrome que podrían enviar contenido de la página, cookies o credenciales fuera del origen

Varias de estas categorías dependen de entradas del entorno, como los destinos remotos sensibles y los alcances de IaC protegidos, que puedes restringir a nombres concretos.

Claude Code v2.1.198 y posterior también bloquean lo siguiente de forma predeterminada:

  • Eliminar archivos en /tmp, $TMPDIR u otro directorio compartido temporal o de caché mediante comodín, glob o filtro de antigüedad, en lugar de mediante una ruta nombrada específica
  • Incluir detalles sensibles en contenido enviado, cargado, publicado o escrito para otras personas o sistemas compartidos, cuando tu propio mensaje no autorizó esos detalles para ese destinatario. Los cuerpos de PR e issues, los mensajes de commit y los comentarios cuentan como este tipo de contenido saliente cuando el repositorio está fuera del límite de confianza o es público, incluidos los repositorios públicos de tu propia organización; las rutas de archivo internas, los nombres en clave, los datos vigentes de respuestas de API, como correos electrónicos o identificadores de cuenta, y los identificadores de infraestructura cuentan como detalles sensibles. La delimitación para PR, issues y mensajes de commit requiere Claude Code v2.1.200 o posterior. Los datos personales vigentes de una respuesta de API en el cuerpo de un PR o issue, como una dirección de correo electrónico, un identificador de cuenta u organización o una métrica de uso, requieren que nombres esos detalles y el destinatario, independientemente de la visibilidad del repositorio o del límite de confianza. Esa verificación requiere Claude Code v2.1.203 o posterior
  • Enviar pulsaciones de teclas al propio panel de tmux de Claude Code para controlar su propia interfaz, lo que el clasificador trata como si Claude cambiara sus propios permisos o su supervisión

Claude Code v2.1.200 y posterior también bloquean lo siguiente de forma predeterminada:

  • Comentar, eliminar o forzar el éxito de una prueba o aserción que protege un comportamiento de seguridad, como autenticación, control de acceso, validación de entradas o sandboxing
  • Eliminar o desmantelar un recurso con estado que Claude no creó en la sesión, cuando no se aplica ninguna regla de eliminación más específica y no nombraste ese recurso
  • Reapuntar una URL base de API, un endpoint de proxy, un receptor de webhooks o un mirror de registro a un host de terceros que no corresponde a la tarea, incluso en archivos de ejemplo como .env.example
  • Cambiar a dónde van los push con git remote set-url o git remote add, a menos que hayas nombrado el nuevo remoto
  • Hacer push de secretos o de datos personales o confiados a un repositorio que se sabe que es público, o hacer push allí de material confidencial que no forma parte del trabajo propio de ese repositorio. El tema propio de un repositorio de dotfiles es la única excepción para los datos personales o confiados, y el contenido de un repositorio privado que llega a cualquier superficie pública se bloquea de la misma manera; ambos refinamientos requieren Claude Code v2.1.203 o posterior. Antes de v2.1.203, los datos personales se agrupaban con el material confidencial y se bloqueaban solo cuando no formaban parte del trabajo propio de ese repositorio. Cuando no se ha establecido la visibilidad de un repositorio, el clasificador no bloquea solo por eso; en su lugar, juzga el contenido según las demás reglas
  • Abrir un pull request contra un repositorio u organización diferente, hacer un fork con gh repo fork o hacer push a un repositorio de terceros, a menos que hayas nombrado ese destino externo

Claude Code v2.1.203 y posterior también bloquean lo siguiente de forma predeterminada:

  • Contenido de un almacén local sensible, o de un archivo cuyo nombre, ruta o tipo lo marca como sensible, que entre en un commit, un push, el texto de un PR o issue, un gist o paste, o la publicación de un paquete, a menos que hayas nombrado tanto el origen como el destino. Cuentan las transcripciones de sesión y los registros de conversación, las carpetas ocultas de credenciales y configuración, como claves SSH, credenciales de la nube, perfiles de navegador e historial del shell, y las exportaciones de datos de usuarios, y que el repositorio sea privado no lo exime

Claude Code v2.1.205 y posterior también bloquean lo siguiente de forma predeterminada:

  • Escribir en las transcripciones de sesión de Claude Code, los archivos de historial .jsonl en ~/.claude/projects/ o en tu directorio de configuración configurado, ya sea directamente o mediante un comando de shell. La regla también cubre las líneas de metadatos que Claude Code agrega a cada entrada de la transcripción para sus propias verificaciones. Leer una transcripción no se bloquea

  • Una eliminación forzada recursiva como rm -rf "$VAR" o Remove-Item -Recurse -Force $dir cuyo destino es una variable de shell que no se asigna en ninguna parte de la conversación que ve el clasificador, o un glob que parte de esa variable. El valor provino solo de la salida de un comando anterior, que el clasificador nunca recibe, por lo que el clasificador no puede verificar el destino de la eliminación según las demás reglas de eliminación. El bloqueo se levanta cuando nombras la ruta exacta que se elimina, o cuando Claude vuelve a ejecutar la eliminación con la ruta literal resuelta escrita en el comando. Las eliminaciones cuyo destino el clasificador puede resolver no se ven afectadas.

    Un glob directamente bajo la variable, como en rm -rf "$VAR"/*, es en cambio una ruta crítica. Los destinos de Remove-Item que son un * solo o que terminan en /* o \* nunca llegan al clasificador: Claude Code los deniega directamente.

Claude Code v2.1.257 y posterior también bloquean lo siguiente de forma predeterminada:

  • Solicitar credenciales al endpoint de metadatos de instancias de la nube, como 169.254.169.254, o autenticar explícitamente una llamada a la nube, a un clúster o a un registro con la identidad de cuenta de servicio o de nodo de la propia máquina
  • Llegar a un host público por una vía distinta de una solicitud directa, como un túnel, un shell inverso o una configuración de resolutor o proxy reescrita para apuntar hacia fuera
  • Leer credenciales que pertenecen al host y no a tu tarea, como certificados de nodo o la autenticación del registro de contenedores del nodo
  • Conectarse a contenedores, pods o máquinas virtuales hermanos que Claude no inició, o escanearlos, o al nodo que está debajo del contenedor

Si Claude Code se ejecuta en un lugar que debe permitir alguna de estas acciones, describe esa configuración en una entrada de Host containment en autoMode.environment.

Claude Code v2.1.261 y posterior también bloquean lo siguiente de forma predeterminada:

  • Publicar o escribir un enlace a un servicio público de paste, diagramas o intercambio de datos en un mensaje, en el texto de un PR o issue, en un documento o en cualquier otro lugar donde el enlace se abrirá o se recuperará, cuando la propia URL contiene el contenido que se comparte, a menos que hayas nombrado ese servicio

Permitido de forma predeterminada:

  • Operaciones con archivos locales en tu directorio de trabajo
  • Instalar dependencias declaradas en tus archivos de bloqueo o manifiestos
  • Leer .env y enviar credenciales a su API correspondiente
  • Solicitudes HTTP de solo lectura
  • Hacer push a cualquier rama del repositorio en el que estás trabajando, incluida la rama predeterminada. Una rama no predeterminada cuyo nombre la marca como destino de implementación o publicación, como production o gh-pages, no está cubierta: el clasificador juzga un push allí según sus propios méritos. El contenido del push se sigue verificando según las demás reglas, las reglas permissions.deny aún pueden bloquear comandos de push tal como están escritos en todos los modos, y la protección de ramas propia del remoto sigue aplicándose. Antes de v2.1.211, solo se permitían de forma predeterminada los push a la rama en la que comenzaste, a las ramas que creó Claude y los push habituales a la rama predeterminada, y antes de v2.1.203 se bloqueaba cualquier push directo a la rama predeterminada
  • Eliminar exactamente los trabajos que Claude creó antes en la misma sesión
  • Leer, revisar o escribir código, configuraciones y modelos de amenazas relacionados con la seguridad como parte de tu tarea
  • Mensajes entre agentes que trabajan juntos en la misma sesión multiagente
  • Enviar datos a los dominios, buckets y servicios de confianza que enumeres en environment. Esto cubre solo el flujo de datos, no operaciones destructivas ni con credenciales en esa misma infraestructura
  • Navegación de Claude in Chrome a un dominio interno de confianza, a localhost o a una URL que nombraste

Los comandos en sandbox no obtienen acceso a la red de forma predeterminada. Claude nombra en el propio comando los hosts que este necesita, el clasificador los revisa junto con el comando, y una lista aprobada abre esos hosts solo para ese comando. Dominios permitidos por comando explica lo que una lista puede y no puede abrir y qué sucede cuando un comando intenta llegar a un host que no está en la lista.

Ejecuta claude auto-mode defaults para imprimir las listas completas de reglas como JSON. Si se bloquean acciones habituales, un administrador puede agregar repositorios, buckets y servicios de confianza mediante el ajuste autoMode.environment: consulta Configurar el modo automático.

Hacer push a cualquier rama del repositorio en el que estás trabajando y crear un pull request que coincide con tu solicitud se ejecutan sin solicitud de permiso, a menos que el push o el pull request entre en la lista de bloqueos, como secretos o datos sensibles que salen del repositorio, o un pull request que apunta a un repositorio u organización diferente. Para exigir un punto de control humano antes de estos comandos sin salir del modo automático, agrega reglas permissions.ask, que coinciden con el comando tal como está escrito: consulta Límites comunes.

La primera lectura fuera de los directorios de trabajo

Mientras permissions.blockReadsOutsideWorkingDirectories está desactivado, las lecturas de archivos se ejecutan sin solicitud de permiso en modo automático, incluidas las lecturas fuera de los directorios de trabajo. La primera vez que Claude usa la herramienta Read, Grep o Glob en una ruta fuera de ellos, Claude Code pregunta si permitir esa lectura.

La solicitud no aparece en ejecuciones -p no interactivas ni en sesiones en segundo plano; allí las lecturas se ejecutan como antes.

Respondas lo que respondas, Claude sigue trabajando:

  • Sí, y seguir permitiendo cualquier lectura fuera de los directorios de trabajo: la lectura se ejecuta, las lecturas posteriores fuera de los directorios de trabajo se ejecutan como antes, y Claude Code registra tu respuesta para que la solicitud no vuelva a aparecer
  • No, y bloquear las lecturas fuera de los directorios de trabajo de ahora en adelante: la lectura se rechaza, y Claude Code establece permissions.blockReadsOutsideWorkingDirectories en true en tu configuración de usuario, lo que hace que las herramientas de archivos rechacen esas lecturas en todas las sesiones posteriores y en todos los modos de permisos. Para permitir que Claude lea una ruta así más adelante, agrega su directorio con /add-dir o elimina el ajuste.
  • No, y volver a preguntar la próxima vez: la lectura se rechaza, y la próxima lectura fuera de los directorios de trabajo vuelve a pedir confirmación
  • Sí, pero volver a preguntar la próxima vez: la lectura se ejecuta, no se guarda nada, y la próxima lectura fuera de los directorios de trabajo vuelve a pedir confirmación

Límites que estableces en la conversación

El clasificador trata los límites que estableces en la conversación como una señal de bloqueo. Si le dices a Claude "no hagas push" o "espera a que revise antes de implementar", el clasificador bloquea las acciones correspondientes incluso cuando las reglas predeterminadas las permitirían. Un límite permanece en vigor hasta que lo levantes en un mensaje posterior. El propio juicio de Claude de que se cumplió una condición no lo levanta.

Los límites no se almacenan como reglas. El clasificador los vuelve a leer de la transcripción en cada verificación, por lo que un límite puede perderse si la compactación del contexto elimina el mensaje que lo estableció. Para una garantía firme, agrega en su lugar una regla de denegación.

Aprobaciones que estableces en la conversación

Si le dices a Claude que una acción bloqueada está permitida, el clasificador lo interpreta como tu aprobación y puede levantar el bloqueo. La forma en que lo expresaste decide si la acción se ejecuta y hasta dónde llega la aprobación:

  • Nombra la acción y sus detalles: tu mensaje tiene que nombrar la acción y lo específico que la hace peligrosa, como la rama de un push forzado. Nombrar solo el verbo no levanta nada, así que "puedes hacer push forzado" deja el bloqueo en su lugar.
  • Cuenta con que cubra una sola acción: una aprobación cubre la acción destructiva que nombraste, por lo que una acción posterior se vuelve a bloquear a menos que hayas otorgado la aprobación como permanente. Para dejar de aprobar un patrón habitual acción por acción, agrégalo a autoMode.allow.
  • Algunos bloqueos se mantienen: el orden de precedencia del clasificador establece qué bloqueos puede alcanzar tu aprobación. Para ejecutar un paso que no se levanta, sal del modo automático y responde la solicitud de permiso.

Cuando el modo automático recurre a solicitudes de permiso

Cuando el modo automático no puede aprobar las acciones de tu sesión, lo que sucede depende del caso:

  • Una acción bloqueada: Claude Code muestra una notificación y lista la acción en /permissions en la pestaña Denegadas recientemente, donde puedes presionar r para reintentarla con una aprobación manual.
  • Bloqueos repetidos: si el clasificador bloquea una acción 3 veces seguidas o 20 veces en total, el modo automático se pausa y Claude Code vuelve a pedir confirmación. Aprobar la acción solicitada reanuda el modo automático. Consulta Umbrales de bloqueos repetidos para saber cómo se cuentan los bloqueos.
  • Sin veredicto del clasificador: cuando una verificación de seguridad independiente del modo automático rechaza la propia solicitud del clasificador, o la respuesta del clasificador no se puede analizar, Claude Code deniega la acción sin la notificación ni la entrada en Denegadas recientemente. Consulta El modo automático no puede determinar la seguridad de una acción para ver el mensaje que muestra cada caso y qué hacer.
  • Sin veredicto del servidor: con la revisión del clasificador del lado del servidor, Claude Code deniega una acción para la que el servidor no da veredicto, y detiene el turno después de diez respuestas seguidas sin veredicto. Consulta El servidor no devolvió ningún veredicto de seguridad.
  • Un cambio de modo durante una verificación: si cambias de modo de permisos mientras una verificación del clasificador está pendiente, Claude Code descarta un veredicto que el nuevo modo no habría solicitado. En su lugar, se te pide aprobación, o la acción se deniega automáticamente en el modo dontAsk.

Umbrales de bloqueos repetidos

Los umbrales de 3 bloqueos seguidos y 20 bloqueos en total no son configurables. El contador total persiste durante la sesión y se reinicia solo cuando su propio límite hace que se recurra a las solicitudes de permiso. Claude Code no cuenta una denegación para ninguno de los umbrales cuando una verificación de seguridad independiente del modo automático rechaza la propia solicitud del clasificador.

Una ejecución -p no interactiva sin --permission-prompt-tool no tiene ninguna solicitud de permiso a la que recurrir. Cuando los bloqueos repetidos alcanzan un umbral, la acción no se ejecuta y Claude sigue trabajando. Claude Code no detiene la ejecución.

Los bloqueos repetidos suelen significar que al clasificador le falta contexto sobre tu infraestructura. Usa /feedback para informar falsos positivos, o pide a un administrador que configure infraestructura de confianza.

Cómo el modo automático evalúa las acciones

Las siguientes secciones explican el orden en que Claude Code evalúa una acción, cómo el clasificador revisa el trabajo de los subagentes y qué agregan las llamadas al clasificador en costo y latencia.

Cada acción pasa por un orden de decisión fijo. Gana el primer paso que coincide: 
1. Las acciones que coinciden con tus [reglas de permitir, preguntar o denegar](/docs/es/permissions#manage-permissions) se resuelven de inmediato, con estas excepciones:
   * Las escrituras en [rutas protegidas](#protected-paths) se envían al clasificador incluso cuando coincide una regla de permitir
   * Ninguna regla de permitir aprueba eliminaciones con `rm` y `rmdir` dirigidas a una [ruta crítica](#critical-paths)
   * Las herramientas MCP marcadas con [`requiresUserInteraction`](/docs/es/mcp#require-approval-for-a-specific-tool) te piden confirmación directamente incluso cuando coincide una regla de permitir, y lo mismo ocurre con las herramientas de conectores que [tu organización estableció en `ask`](/docs/es/mcp#organization-controls-on-connector-tools) en las sesiones donde ese ajuste llega a Claude Code
   * Un comando de shell que lleva [dominios permitidos por comando](/docs/es/sandboxing#per-command-allowed-domains-in-auto-mode) también se envía al clasificador incluso cuando coincide una regla de permitir, porque una regla aprueba el comando, no sus hosts
   * Las reglas de preguntar que coinciden con el contenido de un comando, como `Bash(git push *)`, recurren a una solicitud de permiso
   * Una escritura que la [verificación de enlaces simbólicos](/docs/es/permissions#symlinks) resuelve a una ruta protegida te pide confirmación cuando la ruta que Claude solicitó no está protegida en sí misma
2. Las acciones de solo lectura y las ediciones de archivos en tu directorio de trabajo se aprueban automáticamente, excepto las escrituras en [rutas protegidas](#protected-paths) y [la primera lectura fuera de los directorios de trabajo](#first-read-outside-the-working-directories), que te pide confirmación
   * En una sesión con [revisión del clasificador del lado del servidor](#server-side-classifier-review), los comandos de shell de solo lectura y [en sandbox](/docs/es/sandboxing#sandbox-modes) esperan esa revisión y se bloquean si esta los marca
   * Una escritura dentro de tu directorio de trabajo que la [verificación de enlaces simbólicos](/docs/es/permissions#symlinks) resuelve a una ubicación fuera de él te pide confirmación
   * Cuando Claude lee un [artefacto creado por otra persona](/docs/es/artifacts#read-an-artifact-shared-with-you), se aplican los casos de aprobación enumerados en esa sección
3. Todo lo demás va al clasificador, salvo las [eliminaciones de rutas críticas](#critical-paths) con su tratamiento predeterminado. Las herramientas de conectores y las herramientas MCP con `requiresUserInteraction` que te piden confirmación directamente en el paso 1 tampoco llegan nunca al clasificador, por lo que ni una aprobación exigida por la organización ni un paso de consentimiento se aprueban automáticamente
4. Si el clasificador bloquea, Claude recibe el motivo. En la mayoría de las sesiones, el motivo nombra la regla con la que coincidió el clasificador, como `[Data Exfiltration]`, en lugar de dar una explicación escrita; consulta [Revisar denegaciones](/docs/es/auto-mode-config#review-denials)

Un [mod](/docs/es/plugins/mods/overview) que instales y que gestione `tool.check` puede aprobar una acción antes del paso 3, y el clasificador no verifica una acción que el mod aprueba. Consulta [Extender permisos con hooks](/docs/es/permissions#extend-permissions-with-hooks).

Al entrar en modo automático, se descartan las reglas de permitir amplias que otorgan ejecución de código arbitrario:

* `Bash(*)` o `PowerShell(*)` sin restricciones
* Intérpretes con comodín como `Bash(python*)`
* Comandos de ejecución del administrador de paquetes
* Reglas de permitir `Agent`
* Reglas de permitir [`Monitor`](/docs/es/tools-reference#monitor-tool), porque Claude Code ejecuta los comandos de Monitor a través del shell

Las reglas específicas como `Bash(npm test)` permanecen en vigor. Claude Code restaura las reglas descartadas cuando sales del modo automático. Antes de v2.1.236, Claude Code dejaba en vigor las reglas de permitir `Monitor` en modo automático, por lo que una regla que coincidía con toda la herramienta aprobaba comandos de Monitor sin revisión del clasificador.

Claude Code también ejecuta `git status` por su cuenta antes de un comando que descartaría trabajo sin confirmar, como `git reset --hard` o `rm -rf`, y le muestra al clasificador si hay trabajo preparado, modificado o sin seguimiento. Claude Code informa los archivos sin seguimiento en esa verificación incluso cuando la configuración de Git del repositorio establece `status.showUntrackedFiles=no`.

En las solicitudes al clasificador que envía el propio Claude Code, el clasificador ve los mensajes del usuario, las llamadas a herramientas distintas de las consultas de solo lectura, como lecturas de archivos y búsquedas, y tu contenido de CLAUDE.md. Los resultados de las herramientas se eliminan de esas solicitudes, por lo que el contenido hostil de un archivo o una página web no puede manipular directamente al clasificador.

Puedes anotar el resultado de una llamada con el [campo `classifierContext` de un hook PostToolUse](/docs/es/hooks#annotate-a-result-for-the-auto-mode-classifier), que el clasificador lee como contexto proporcionado por la aplicación. El campo requiere Claude Code v2.1.236 o posterior.

Una sonda independiente del lado del servidor analiza los resultados de herramientas entrantes y marca el contenido sospechoso antes de que Claude lo lea. Para obtener más información sobre cómo funcionan juntas estas capas, consulta el [anuncio del modo automático](https://claude.com/blog/auto-mode) y el [análisis técnico en profundidad](https://www.anthropic.com/engineering/claude-code-auto-mode).
Cómo el modo automático maneja los subagentes

El clasificador verifica el trabajo de los subagentes en tres puntos:

  1. Antes de que comience un subagente, se evalúa la descripción de la tarea delegada, por lo que una tarea de aspecto peligroso se bloquea en el momento de crear el subagente.
  2. Mientras el subagente se ejecuta, cada una de sus acciones pasa por el mismo orden de decisión que en la sesión principal, con las mismas reglas de bloqueo y de permitir. Cualquier permissionMode en el frontmatter del subagente se ignora.
  3. Cuando el subagente termina, el clasificador revisa su trabajo y su informe final antes de que la sesión principal lea el informe. Cuando el clasificador marca el trabajo o el informe del subagente, o una verificación de seguridad independiente de la API rechaza la revisión, el informe se entrega de todos modos, precedido de una advertencia de seguridad. Cuando el clasificador no está disponible para la revisión, el informe llega con una nota para verificar el trabajo del subagente antes de actuar en función de él.
Costo y latencia

El clasificador se ejecuta en Claude Sonnet 5 de forma predeterminada, en lugar de en tu selección de /model. Un modelo clasificador que Anthropic configura del lado del servidor tiene precedencia sobre ese valor predeterminado. Cuando el modelo de tu sesión es Claude Sonnet 4.6, o cuando availableModels excluye Sonnet 5, el clasificador se ejecuta en cambio en el modelo de la sesión, o en un modelo Opus cuando la sesión se ejecuta en un modelo Fable. En proveedores distintos de la API de Anthropic, ese respaldo de Opus es el modelo que establezcas en ANTHROPIC_DEFAULT_OPUS_MODEL, u Opus 5 si no has establecido ninguno.

La primera solicitud de modo automático de la sesión valida el predeterminado de Sonnet 5: si la solicitud tiene éxito, Sonnet 5 permanece como el modelo clasificador de la sesión, y si falla porque el modelo no está disponible, la sesión usa el respaldo en su lugar.

En los planes Enterprise y en cuentas que usan la API de Claude, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform o Microsoft Foundry, las llamadas al clasificador cuentan para tu uso de tokens. Cada verificación envía una parte de la transcripción más la acción pendiente, lo que agrega un viaje de ida y vuelta antes de la ejecución. Las lecturas y las ediciones en el directorio de trabajo fuera de rutas protegidas omiten el clasificador, por lo que la sobrecarga proviene principalmente de los comandos de shell y las operaciones de red. Donde el servidor revisa las acciones como parte de las solicitudes al modelo de la sesión, no hay llamadas separadas al clasificador que contar; consulta Revisión del clasificador del lado del servidor.

El acceso a la red en sandbox no agrega solicitudes al clasificador por conexión. El clasificador juzga los hosts que nombra un comando junto con el comando en una sola revisión, y Claude Code verifica cada conexión contra la lista aprobada sin volver a llamar al clasificador.

Permitir solo herramientas preaprobadas con modo dontAsk

Si establece el modo dontAsk, Claude Code deniega automáticamente cada llamada de herramienta que de otro modo le solicitaría. Claude aún ejecuta acciones que no necesitan aprobación en modo Manual, como lecturas de archivos dentro de sus directorios de trabajo y comandos Bash de solo lectura, además de acciones que coinciden con sus reglas permissions.allow y llamadas aprobadas por un hook PreToolUse. Utilice este modo para canalizaciones de CI o entornos restringidos donde predefine qué puede hacer Claude; la sesión nunca espera entrada. La barra de estado muestra ⏵⏵ don't ask on mientras este modo está activo.

Claude Code deniega llamadas que coincidan con sus reglas ask explícitas en lugar de solicitar. También deniega la herramienta integrada AskUserQuestion incluso si sus reglas de permitir coinciden, y hace lo mismo con las herramientas de conector que su organización estableció en ask en sesiones donde esa configuración llega a Claude Code. Deniega las herramientas MCP marcadas _meta["anthropic/requiresUserInteraction"] de la misma manera, porque su tarjeta de aprobación necesita una respuesta que este modo nunca recopila; esto requiere Claude Code v2.1.199 o posterior.

Las eliminaciones rm y rmdir dirigidas a una ruta crítica, como rm -rf / y rm -rf ~, se deniegan incluso cuando una regla de permitir coincide con ellas o un hook PreToolUse las permite.

Las sesiones en la nube en Claude Code en la web ignoran defaultMode: "dontAsk"; consulte bypassPermissions para obtener detalles.

Establézcalo al inicio con la bandera:

claude --permission-mode dontAsk

Omitir todas las comprobaciones con modo bypassPermissions

El modo bypassPermissions desactiva los avisos de permisos y las comprobaciones de seguridad para que las llamadas a herramientas se ejecuten inmediatamente, incluidas las escrituras en rutas protegidas.

Las acciones que ningún modo aprueba automáticamente siguen pidiendo confirmación en este modo. Leer el artefacto público de otra organización requiere tu aprobación, y este modo no la solicita, así que Claude no puede leer uno. Las denegaciones de Remove-Item en PowerShell también se aplican en este modo.

Dos salvaguardas de mensajería entre sesiones aún se aplican en este modo, y en sesiones de modo plan de terminal interactivo donde los permisos de omisión están disponibles:

  • El aviso de aprobación isolatePeerMachines para mensajes a sus sesiones más allá de esta máquina aún aparece.
  • Cuando no se aplica ningún valor crossSessionInbound, Claude Code retiene un mensaje entrante de otra de sus sesiones para su aprobación, y entrega sin preguntar solo cuando la sesión de envío se identifica a sí misma como también omitiendo avisos de permisos. Si deja el modo de permisos mientras se retienen mensajes, Claude Code reaaplica las reglas entrantes y entrega cualquier mensaje retenido que ahora aceptan.

En sesiones de terminal interactivo con permisos de omisión disponibles, Claude Code tampoco aplica los bloqueos del modo plan. Claude aún recibe instrucciones de planificar sin editar, pero una edición de archivo o comando de shell que intenta durante la planificación se ejecuta sin solicitar. Las reglas ask explícitas y las eliminaciones rm y rmdir dirigidas a una ruta crítica aún solicitan.

El modo plan mantiene sus bloqueos dondequiera que Claude Code se ejecute sin un terminal interactivo, incluidas ejecuciones no interactivas con -p, sesiones de Agent SDK, y conversaciones en el panel de chat de la extensión VS Code. Allí, --allow-dangerously-skip-permissions hace que bypassPermissions sea seleccionable más tarde.

No puede entrar en bypassPermissions desde una sesión que inició sin él habilitado. Habilítelo al inicio con permissions.defaultMode: "bypassPermissions" o con una bandera de habilitación:

claude --permission-mode bypassPermissions

La bandera --dangerously-skip-permissions es equivalente.

Claude Code rechaza bypassPermissions en una sesión que inicia con --restricted. --restricted requiere Claude Code v2.1.248 o posterior.

La primera vez que inicia una sesión interactiva con este modo habilitado, Claude Code muestra un diálogo de advertencia pidiéndole que acepte la responsabilidad por acciones tomadas sin comprobaciones de permisos:

  • Si acepta: Claude Code establece skipDangerousModePermissionPrompt en true en ~/.claude/settings.json, por lo que las sesiones posteriores omiten el diálogo. Para ver el diálogo nuevamente, elimine la clave de ese archivo o establézcala en false. La referencia skipDangerousModePermissionPrompt enumera los otros archivos de configuración donde usted u su organización pueden establecerla.
  • Si rechaza: Claude Code sale.

En modo no interactivo no se muestra diálogo, y una sesión en segundo plano iniciada con --bg se rechaza hasta que haya aceptado el diálogo en una sesión interactiva.

En Linux y macOS, Claude Code se niega a iniciarse en este modo cuando se ejecuta como root o bajo sudo:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

La verificación se omite automáticamente dentro de un sandbox reconocido. Para ejecutarse de forma autónoma en un contenedor, use la configuración de dev container, que ejecuta Claude Code como un usuario no root.

Las sesiones en la nube no respetan defaultMode: "bypassPermissions" o "dontAsk" de sus archivos de configuración, por lo que la configuración registrada en un repositorio no puede iniciar una sesión en la nube en modo bypass-permissions. La configuración se ignora silenciosamente y la sesión comienza en el modo de permisos mostrado en el menú desplegable de modo en su lugar. Consulte Cambiar modos de permisos para ver qué modos ofrecen las sesiones en la nube.

Rutas protegidas

Las escrituras en un pequeño conjunto de rutas nunca se aprueban automáticamente, excepto en modo bypassPermissions y en sesiones de terminal interactivas en modo plan con permisos de omisión disponibles. Esto previene la corrupción accidental del estado del repositorio y la configuración de Claude.

Modo Escrituras en rutas protegidas
default, acceptEdits Solicitadas
plan Permitidas en sesiones de terminal interactivas con permisos de omisión disponibles. De lo contrario, enrutadas al clasificador cuando modo automático está disponible durante la planificación, y solicitadas cuando no lo está
auto Enrutadas al clasificador
dontAsk Denegadas
bypassPermissions Permitidas

En una sesión iniciada con --restricted, que requiere Claude Code v2.1.248 o posterior, el clasificador no puede aprobar escrituras en rutas protegidas.

En los modos que enrutan escrituras en rutas protegidas al clasificador, una escritura que la verificación de enlaces simbólicos resuelve a una ruta protegida le solicita en su lugar cuando la ruta que Claude solicitó no está protegida en sí misma.

Las reglas permissions.allow en archivos de configuración no pre-aprueban escrituras en rutas protegidas. La verificación de seguridad se ejecuta antes de que Claude Code evalúe las reglas de permitir desde la configuración, por lo que una entrada como Edit(.claude/**) en ~/.claude/settings.json o .claude/settings.json no cambia el resultado por modo en la tabla anterior. En modos de permisos que solicitan, el aviso para una escritura en la carpeta .claude/ del proyecto o en ~/.claude/ puede ofrecer una de estas opciones con alcance de sesión:

  • Para la carpeta .claude/ del proyecto: Sí, y permitir que Claude edite archivos en la carpeta .claude de este proyecto para esta sesión
  • Para ~/.claude/: Sí, y permitir que Claude edite archivos en su carpeta ~/.claude para esta sesión

Directorios protegidos:

  • .git
  • .config/git
  • .vscode
  • .idea
  • .husky
  • .cargo
  • .devcontainer
  • .yarn
  • .mvn
  • .claude, excepto por .claude/worktrees donde Claude almacena sus propios git worktrees
  • Un directorio que cargó con --plugin-dir, porque Claude Code recarga y ejecuta el código de un mod desde él cuando un archivo cambia

Archivos protegidos:

  • .gitconfig, .gitmodules
  • .bashrc, .bash_profile, .bash_login, .bash_aliases, .bash_logout, .zshrc, .zprofile, .zshenv, .zlogin, .zlogout, .profile, .envrc
  • .npmrc, .yarnrc, .yarnrc.yml, .pnp.cjs, .pnp.loader.mjs, .pnpmfile.cjs, bunfig.toml, .bunfig.toml
  • .bazelrc, .bazelversion, .bazeliskrc
  • .pre-commit-config.yaml, lefthook.yml, lefthook.yaml, .lefthook.yml, .lefthook.yaml
  • gradle-wrapper.properties, maven-wrapper.properties
  • .devcontainer.json
  • .ripgreprc, pyrightconfig.json
  • .mcp.json, .claude.json

Rutas críticas

Las rutas críticas son los directorios que Claude Code protege de los comandos rm y rmdir, como la raíz del sistema de archivos, su directorio de inicio y su directorio de trabajo.

Claude Code nunca permite que una regla permissions.allow o un hook PreToolUse que devuelve "allow" apruebe un comando rm o rmdir que se dirija a una ruta crítica, incluso en modos que omiten otros avisos. Este cortacircuitos protege contra errores del modelo. Una regla de denegación coincidente aún bloquea el comando completamente.

Lo que sucede en su lugar depende de su modo de permisos. Remove-Item y los comandos integrados de eliminación de cmd tienen sus propias verificaciones, cubiertas en Remove-Item en PowerShell.

Qué rutas son críticas

Claude Code trata un objetivo rm o rmdir como una ruta crítica cuando es cualquiera de los siguientes:

  • La raíz del sistema de archivos
  • Directorios de nivel superior, lo que significa cualquier hijo directo de la raíz, como /usr, /etc o /data
  • Su directorio de inicio
  • Raíces de unidad de Windows y sus directorios de nivel superior, como C:\ y C:\Windows
  • Su directorio de trabajo y sus padres
  • Sus directorios de trabajo adicionales y sus padres, pero solo cuando la eliminación es un glob bajo uno de ellos, como rm -rf <dir>/*. rm -rf <dir> en el directorio en sí no desencadena esta verificación

Otros objetivos que cuentan como rutas críticas

Claude Code también trata los siguientes objetivos rm y rmdir como rutas críticas. La última columna dice por qué cada uno cuenta.

Objetivo Ejemplo Por qué cuenta
Un glob o barra diagonal final directamente bajo una variable de shell rm -rf "$DIR"/* El comando se convierte en una eliminación desde la raíz del sistema de archivos cuando la variable está vacía
La misma forma bajo un parámetro posicional como $1 o $@, cuando nada en el comando le da un valor rm -rf "$1"/* El comando se expande a una eliminación desde la raíz
Una variable de shell seguida de un nombre de directorio de nivel superior común, como mnt, tmp, usr o Users rm -rf "$TMPDIR/mnt" Cuando la variable se expande vacía, el comando elimina /mnt
Una variable que el mismo comando asigna desde una sustitución de impresión de directorio, como $(pwd) o $(git rev-parse --show-toplevel) D=$(pwd); rm -rf "$D" El valor puede nombrar su directorio de trabajo o raíz del repositorio
Un objetivo que es solo la salida de una sustitución de comando, cuando el rm es recursivo rm -rf "$(pwd)" Claude Code no puede verificar el objetivo antes de que se ejecute el comando
Una sustitución de comando final después de una ruta crítica rm -rf ~/$(cmd) Claude Code verifica la ruta que permanecería si la sustitución se expandiera vacía, aquí su directorio de inicio
Un objetivo que es solo barras invertidas rm -rf "\\" Git Bash en Windows lee una barra invertida sola como la raíz de la unidad actual, por lo que la verificación se aplica en todas las plataformas

Para desactivar la verificación en un objetivo que es solo salida de sustitución de comando, establezca CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 en el entorno que inicia Claude Code.

Eliminaciones dentro de comandos anidados y scripts en línea

Claude Code también busca dentro de estas construcciones:

  • Comandos anidados: una subshell con (...), un grupo de llaves con { ...; }, sustitución de comandos con $(...) o comillas invertidas, o sustitución de procesos con <(...). Claude Code encuentra una eliminación de ruta crítica ya sea que esté dentro de la forma anidada, como en (rm -rf ~) o echo "$(rm -rf ~)", o en otro lugar del mismo comando.
  • Scripts en línea: Claude Code verifica un script pasado a un shell como sh -c o bash -c para la variable de shell y los objetivos de parámetro posicional targets.
    • Cuando el script está entre comillas dobles, el shell que invoca expande sus variables antes de que el shell interno reciba el script. En find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \;, el comando se expande a una eliminación desde la raíz del sistema de archivos una vez por coincidencia, y Claude Code la trata como una eliminación de ruta crítica.
    • Un script entre comillas simples que vincula $1 a un valor real, como sh -c 'rm -rf "$1"/*' _ {} hace, no se marca.

Reescribir un comando marcado

Cómo reescribir un comando para que pase la verificación depende de cuál de los otros objetivos utiliza:

  • Un glob o barra diagonal final bajo una variable como $DIR: proteja cada expansión para que el shell se detenga con un error cuando la variable no esté configurada o esté vacía, como en rm -rf "${DIR:?}"/*, o use una ruta literal. Una eliminación cuyas expansiones están todas protegidas de esa manera pasa esta verificación, por lo que en modo bypassPermissions se ejecuta sin un aviso a menos que otra verificación de ruta crítica la marque.
  • Un glob o barra diagonal final bajo una variable que normalmente está configurada, como $HOME: use una ruta literal.
  • Una variable asignada desde una sustitución de impresión de directorio: use una ruta literal. Una protección "${D:?}" no borra esta verificación, porque la variable no está vacía.
  • Un objetivo que es solo salida de sustitución de comando: ejecute la sustitución por su cuenta primero, luego elimine las rutas literales que imprime. El aviso le dice a Claude que haga lo mismo.

Para un glob o barra diagonal final bajo una variable, el aviso nombra el rm marcado y dice cómo reescribirlo para que la verificación pase.

Eliminaciones de rutas críticas en cada modo de permisos

Lo que Claude Code hace con una eliminación de ruta crítica depende de su modo de permisos:

Modo Resultado
default, acceptEdits Le solicita que la apruebe
plan Le solicita que la apruebe. Cuando el clasificador revisa comandos durante la planificación y no hay permisos de omisión disponibles, la maneja como en modo auto
auto Le solicita que la apruebe en la terminal, con un límite de tiempo. En otros lugares, la deniega
dontAsk La deniega
bypassPermissions Le solicita que la apruebe, con un límite de tiempo en la terminal

Si una regla ask explícita coincide con el comando, Claude Code le solicita incluso en modo auto y sin límite de tiempo. En modos que solicitan, un hook PermissionRequest puede responder el aviso.

Límites de tiempo y denegaciones en modos auto y bypassPermissions

En modos auto y bypassPermissions, el aviso de la terminal para una eliminación de ruta crítica muestra una cuenta regresiva de dos minutos:

  • Si la cuenta regresiva se agota antes de que responda, Claude Code deniega el comando y le dice a Claude qué hacer en su lugar, para que una sesión desatendida siga funcionando.
  • Presione cualquier tecla mientras el aviso está abierto para detener la cuenta regresiva y mantener el aviso esperando su respuesta.
  • Después de que tres de estos avisos se agoten sin respuesta en una sesión, Claude Code deja de mostrarlos y deniega las eliminaciones de rutas críticas posteriores inmediatamente. Enviar un nuevo mensaje reinicia el contador.

En modo auto, dondequiera que Claude Code no pueda mostrarle un aviso de terminal, deniega el comando inmediatamente, por ejemplo en ejecuciones no interactivas con -p, en sesiones de Agent SDK, y en el panel de chat de la extensión de VS Code y la aplicación de escritorio. La denegación le dice a Claude que informe qué quería eliminar y deje la eliminación para usted.

El manejo de auto y bypassPermissions requiere Claude Code v2.1.281 o posterior. Para desactivarlo, establezca CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1 en el entorno que inicia Claude Code. En modo auto, las eliminaciones de rutas críticas van al clasificador en su lugar, y en modo bypassPermissions el aviso no tiene límite de tiempo.

Remove-Item en PowerShell

Cuando habilita la herramienta PowerShell, Claude Code da a Remove-Item y a los comandos integrados de cmd rd, rmdir, del y erase sus propias verificaciones, separadas de la lista de rutas críticas rm. Para Remove-Item, el resultado depende del objetivo, y se aplica el primer caso coincidente:

  • Rutas del sistema: la raíz del sistema de archivos y sus directorios de nivel superior, raíces de unidad y sus directorios de nivel superior, y su directorio de inicio. Claude Code deniega el comando en todos los modos, sin solicitarle.
  • Comodines: un * desnudo, o cualquier objetivo que termine en /* o \*, incluido un glob bajo una variable de shell como $dir/*. Claude Code deniega el comando en todos los modos, sin solicitarle, antes de que el clasificador lo vea.
  • Su directorio de trabajo o uno de sus padres, con -Recurse: Claude Code trata el comando como cualquier otro que necesita aprobación en su modo de permisos, por lo que le solicita en modos que solicitan, lo envía al clasificador en modo auto y lo deniega en modo dontAsk. El modo bypassPermissions omite esta verificación.

El caso de rutas del sistema también se aplica a rd, rmdir, del y erase cuando Claude los ejecuta a través de cmd, como en cmd /c rd /s /q C:\Users. De forma predeterminada, Claude Code deniega tal comando en todos los modos, sin solicitarle. Esta verificación de cmd requiere Claude Code v2.1.283 o posterior.

Al juzgar un objetivo de cmd, Claude Code trata una variable de PowerShell que sigue texto literal como vacía. Eso hace que cmd /c rd /s /q "C:\$name" sea una eliminación de C:\, por lo que también se deniega. Un comodín final cuenta como la carpeta que vacía, por lo que cmd /c del /q C:\* se deniega y cmd /c del /q dist\* en su proyecto no.

Para desactivar la verificación de cmd, establezca CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1 en el entorno que inicia Claude Code. Claude Code ignora esta variable en el bloque env de un archivo de configuración. Remove-Item en una ruta del sistema permanece denegado de cualquier manera.

Véase también

  • Permisos: reglas de permitir, solicitar y denegar; políticas administradas
  • Configurar modo automático: indique al clasificador qué infraestructura confía su organización
  • Hooks: lógica de permisos personalizada mediante hooks PreToolUse y PermissionRequest
  • Seguridad: salvaguardas y mejores prácticas
  • Sandboxing: aislamiento del sistema de archivos y red para comandos Bash
  • Modo no interactivo: ejecutar Claude Code con la bandera -p