Elige un modo de permisos

Controla si Claude pregunta antes de actuar. Cambia de modo de permisos con Shift+Tab en la CLI, el indicador de modo en VS Code o el selector de modo en Desktop.

Un modo de permisos define qué acciones puede realizar Claude en una sesión sin preguntarte primero. En el modo Manual, Claude Code se detiene y te pregunta antes de la mayoría de las acciones que editan archivos, ejecutan comandos de shell o acceden a la red. En el modo automático, un segundo modelo, el clasificador, revisa las acciones en tu lugar; cómo evalúa las acciones el clasificador enumera qué acciones revisa y cuáles lo omiten.

Con Claude Code v2.1.283 o posterior, el modo automático es el modo de permisos inicial integrado para las sesiones interactivas de la terminal y de VS Code. En versiones anteriores, es el modo de permisos inicial integrado solo en los planes Pro, Max, Ultra y Team. En qué modo se inicia una sesión explica las superficies y los ajustes que cambian el modo de permisos inicial. También puedes cambiar el modo de permisos de una sesión en curso 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.

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 escribas el valor, por ejemplo claude --permission-mode manual o "defaultMode": "manual".

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, aunque puedes desactivar la solicitud de permiso para comandos rm peligrosos en modo 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 reconocidas de rm y rmdir en rutas críticas, que ninguna regla de permitir ni "allow" de un hook PreToolUse aprueba, y comandos Bash marcados con Dangerous rm operation not ruled out

• 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.

• Escrituras fuera de los directorios de trabajo mientras permissions.blockWritesOutsideWorkingDirectories está activado: Claude Code rechaza las llamadas a Write, Edit y NotebookEdit allí, aparte de algunos de sus propios archivos. La clave no limita los comandos de shell, las herramientas MCP ni los programas que ejecutan los hooks, así que usa sandboxing para limitar dónde escriben los comandos de shell. Requiere Claude Code v2.1.314 o posterior.

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.

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 inicias 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 estableces "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 estableces "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, consulta 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 ejecutes Claude Code. La primera fila que coincida con tu sesión se aplica. La tabla cubre sesiones que inicias en una terminal o a través de la extensión de VS Code; para la aplicación de escritorio y claude.ai, consulta las pestañas Desktop y Web en Cambiar modos de permisos.

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 tus 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 descartes

Si tu ~/.claude/settings.json establece un defaultMode distinto de auto y ningún otro archivo de configuración establece uno, tus sesiones siguen iniciándose en ese modo.

En planes Pro, Max, Ultra y Team, y en sesiones que no obtienen banderas de características, Claude Code pregunta una vez si deseas cambiar el ajuste a modo automático. La pregunta aparece en la terminal o en la extensión de VS Code, y si rechazas, tu ajuste permanece como está.

Llamadas a herramientas denegadas en ejecuciones de claude -p y del Agent SDK

En Claude Code v2.1.302 o posterior, las ejecuciones de claude -p y del Agent SDK sin un modo de permisos establecido comienzan en modo Manual. Este modo aparece como default en las opciones del SDK y en la configuración. Las llamadas que necesitan aprobación se deniegan a menos que las apruebes con una regla de permiso, un hook, un callback canUseTool o --permission-prompt-tool.

Para que estas llamadas se aprueben, agrega reglas de permiso o comienza en modo automático:

• Agrega reglas de permiso: Claude ejecuta las llamadas que enumeres. Pasa --allowedTools "Bash(npm test)" a claude -p, o establece la opción de herramientas permitidas de tu SDK.
• Comienza en modo automático: un modelo clasificador revisa las llamadas, así que no necesitas enumerar nada de antemano. Pasa --permission-mode auto a claude -p, o establece la opción de modo de permisos de tu SDK.

Estos ejemplos muestran la forma del modo automático para la CLI y cada SDK:

[tab] CLI

claude -p "Run the test suite and fix any failures" --permission-mode auto

[tab] TypeScript

const options = {
  permissionMode: "auto"
};

[tab] Python

from claude_agent_sdk import ClaudeAgentOptions

options = ClaudeAgentOptions(permission_mode="auto")

Antes de v2.1.302, estas ejecuciones podían comenzar en modo automático si no obtenían banderas de características, por ejemplo en un proveedor de terceros o con DISABLE_TELEMETRY.

Comienza en un modo de permisos diferente

Puedes 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, la 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, consulta Cambiar modos de permisos.

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

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

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

Modos de permisos con la configuración HIPAA

En una organización con la configuración HIPAA aplicada, el valor predeterminado integrado auto no se aplica. Una sesión de terminal o de VS Code comienza en modo Manual cuando nada más elige su modo de permisos inicial. Una sesión de terminal también muestra Auto mode isn't the default for your organization · Shift+Tab to switch, y la extensión de VS Code no muestra ningún aviso. Comprueba cómo inician sesión y se conectan los desarrolladores enumera las sesiones a las que se aplica esto.

El modo automático y bypassPermissions siguen disponibles:

• Cambiar a modo automático: presiona Shift+Tab o usa el control de tu interfaz
• Comenzar en modo automático: pasa --permission-mode auto, o establece permissions.defaultMode en auto en tu configuración de usuario, o en la configuración administrada para toda tu organización. Consulta Comienza en un modo de permisos diferente
• Eliminar el modo automático: establece permissions.disableAutoMode en "disable" en la configuración administrada
• Bloquear bypassPermissions: establece permissions.disableBypassPermissionsMode en "disable" en la configuración administrada

Requiere Claude Code v2.1.285 o posterior, la versión mínima para la configuración HIPAA.

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.

[tab] CLI

Durante una sesión: presiona Shift+Tab para alternar entre modos de permisos. Desde auto, la primera pulsación cambia a default, y luego el ciclo sigue default → acceptEdits → plan. Los modos opcionales 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.

Observa la barra de estado en este clip de una sesión que comenzó en modo automático. Cada vez que presionas Shift+Tab, cambia de auto mode on a manual mode on, accept edits on, plan mode on y de vuelta a auto mode on.

[tab] VS Code

Durante una sesión: haga clic en el indicador de modo en la parte inferior del cuadro de solicitud. Utiliza estas etiquetas para los modos en esta página:

Etiqueta de interfaz	Modo
Manual	default
Editar automáticamente	acceptEdits
Plan	plan
Auto	auto
Omitir permisos	bypassPermissions

Como predeterminado: para fijar el modo de permisos en el que comienzan las conversaciones, establezca claudeCode.initialPermissionMode en la configuración de usuario de VS Code en default, manual, acceptEdits, plan o bypassPermissions. La configuración no acepta auto; para comenzar en Auto, déjela sin establecer y seleccione Auto del indicador de modo una vez, como describe el elemento 2 a continuación. La extensión comienza cada nueva conversación en el primero de estos que se aplique:

1. claudeCode.initialPermissionMode
2. El modo que seleccionó por última vez del indicador de modo, si fue Manual, Editar automáticamente o Auto. Seleccionar Plan u Omitir permisos se aplica solo a esa conversación
3. permissions.defaultMode de configuración administrada o ~/.claude/settings.json
4. El valor predeterminado integrado para su plan, proveedor y configuración de organización

La extensión nunca lee .claude/settings.json o .claude/settings.local.json de un proyecto para el modo de permisos inicial. Cuando claudeCode.claudeProcessWrapper está establecido, los elementos 3 y 4 tampoco se aplican: esas conversaciones comienzan en Manual a menos que el elemento 1 o el elemento 2 establezca un modo de permisos.

Antes de v2.1.283, el elemento 3 se aplicaba solo en planes Pro, Max, Ultra y Team en sesiones que obtienen banderas de características.

Auto aparece en el indicador de modo cuando modo automático está disponible.

Omitir permisos requiere el toggle Allow dangerously skip permissions en la configuración de la extensión. Sin él, el modo de permisos no aparece en el indicador, y un valor bypassPermissions del elemento 1 o elemento 3 comienza la conversación en Manual en su lugar. Auto de cualquier elemento asimismo comienza la conversación en Manual cuando el modo automático no está disponible.

Consulta la guía de VS Code para obtener detalles específicos de la extensión.

[tab] JetBrains

El plugin de JetBrains ejecuta Claude Code en la terminal del IDE, por lo que cambiar modos de permisos funciona igual que en la CLI: presiona Shift+Tab para alternar, o pasa --permission-mode al iniciar.

[tab] Desktop

Durante una sesión: en la pestaña Code, usa el selector de modo en la fila debajo del cuadro de prompt. No todos los modos aparecen en el selector:

• Auto: aparece cuando el modo automático está disponible
• Omitir permisos: requiere el toggle Allow bypass permissions mode en la configuración de Desktop en planes Pro, Max y Ultra; en planes Team y Enterprise, la política de la organización lo controla en su lugar

Cowork no utiliza estos modos. Tiene sus propios modos de permisos, habilitados por separado, y no muestra ningún selector de modo en absoluto hasta que se habilita para tu cuenta un modo distinto de su predeterminado. Consulta la documentación de Cowork.

Para detalles específicos de desktop, consulte Elegir un modo de permisos en la guía de Desktop.

Como predeterminado: establezca defaultMode en configuración. La aplicación de desktop lee los mismos archivos de configuración que la CLI y aplica el modo de permisos a nuevas sesiones locales.

Un modo que selecciona en el selector de modo se recuerda por carpeta y tiene prioridad sobre defaultMode para esa carpeta. Plan es la excepción: seleccionarlo se aplica solo a la sesión actual.

Para saber dónde va defaultMode en un archivo de configuración, consulta el ejemplo en Comienza en un modo de permisos diferente.

[tab] Web and mobile

En claude.ai/code, usa el menú desplegable de modo en la fila debajo del cuadro de prompt. En la aplicación móvil, toca el botón + en el cuadro de prompt y luego Permission. Las sesiones en la nube y las sesiones de Remote Control ofrecen modos de permisos diferentes:

• Sesiones en la nube: Aceptar ediciones, Plan y Auto. Aceptar ediciones corresponde al modo default: las sesiones en la nube aprueban previamente las ediciones de archivos independientemente del modo, por lo que el menú desplegable muestra Aceptar ediciones en lugar de Manual. Las sesiones en la nube aún respetan defaultMode: "acceptEdits" de la configuración. El modo Auto aparece solo cuando tu organización lo permite y el modelo seleccionado lo admite. Omitir permisos no está disponible.
• Sesiones de Remote Control en tu máquina local: Manual, Aceptar ediciones, Plan y Auto para una sesión que iniciaste tú mismo, y no puedes seleccionar Omitir permisos desde la aplicación. Para usar Auto, la sesión tiene que cumplir los requisitos de disponibilidad del modo automático. Para un hilo de proyecto que se ejecuta en tu computadora, consulta Ejecutar un hilo en tu propia computadora.
  • Excepto por Omitir permisos, el menú desplegable muestra el modo de permisos en el que se encuentra la sesión local, incluido uno establecido desde la terminal. Se actualiza cuando el modo de permisos cambia en la aplicación o en la terminal.
  • Las sesiones alojadas por la aplicación de desktop o la extensión de VS Code informan los cambios de modo de permisos a claude.ai a medida que suceden, igual que las sesiones alojadas en una terminal.

Para Control Remoto, la máquina local que ejecuta la sesión debe estar conectada con su cuenta de claude.ai; las claves API no son compatibles. También puede establecer el modo de permisos inicial al iniciar esa sesión local:

claude remote-control --permission-mode acceptEdits

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. Excepto touch, 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 tu directorio de trabajo o additionalDirectories.

Estos casos aún solicitan permiso:

• Rutas fuera de ese alcance
• Escrituras en rutas protegidas
• Eliminaciones rm y rmdir reconocidas como eliminaciones de rutas críticas
• touch con cualquier cosa más allá de rutas de archivo simples, por ejemplo una opción, un glob o un prefijo como timeout 5 o LANG=C
• Todos los demás comandos Bash excepto el conjunto integrado de solo lectura

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.

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

Analiza antes de editar con el 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 tu código fuente. Excepto en sesiones interactivas de terminal con bypass permissions disponible, las ediciones permanecen bloqueadas hasta que apruebes 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:

• Sesiones interactivas de terminal con bypass permissions disponible: ni el clasificador ni una solicitud de permiso se aplican a los comandos de planificación. Omite todas las comprobaciones con el modo bypassPermissions cubre las pocas cosas que aún piden confirmación allí.
• Modo automático disponible y el ajuste useAutoModeDuringPlan activado, como lo está de forma predeterminada: el clasificador revisa los comandos de shell distintos de las eliminaciones de rutas críticas en lugar de pedirte confirmación. Los comandos aprobados se ejecutan y los rechazados se bloquean.
• Modo automático no disponible, o useAutoModeDuringPlan desactivado: los comandos fuera del conjunto integrado de solo lectura solicitan aprobación, incluso cuando el modo de permitir automáticamente del sandbox está habilitado.

Entra en el modo plan presionando Shift+Tab o anteponiendo /plan a un único prompt. También puedes iniciar en el modo plan desde la CLI:

claude --permission-mode plan

Presiona Shift+Tab de nuevo para salir del modo plan sin aprobar un plan.

Revisa y aprueba un plan

Cuando el plan está listo, Claude lo presenta y pregunta cómo proceder. Desde esa solicitud puedes elegir:

• Yes, and use auto mode: aprueba e inicia en modo automático. Si el modo automático no está disponible para tu sesión, por ejemplo porque tu organización lo desactivó, esta opción dice Yes, auto-accept edits. Si iniciaste la sesión con bypass permissions habilitado, la opción dice en cambio Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session.
• Yes, manually approve edits: aprueba y revisa cada edición individualmente.
• No, keep planning: permanece en el modo plan y dile 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 de nuevo, vuelve al modo plan con Shift+Tab o antepone /plan a tu siguiente prompt.

Presiona Ctrl+G para abrir el plan propuesto en tu editor de texto predeterminado y editarlo directamente antes de que Claude continúe. Cuando showClearContextOnPlanAccept está habilitado, la lista incluye una primera opción que aprueba el plan y borra el contexto de planificación.

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

Establece el modo plan como predeterminado

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

Elimina las solicitudes de permiso con el modo automático

El modo automático permite que Claude ejecute acciones sin las solicitudes de permiso habituales. Un modelo clasificador independiente revisa las acciones antes de que se ejecuten y bloquea todo lo que vaya más allá de tu solicitud, apunte a infraestructura no reconocida o parezca estar motivado por contenido hostil que Claude haya leído. Las reglas ask explícitas siguen forzando una solicitud de permiso.

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

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

De forma predeterminada, el clasificador no revisa las eliminaciones de rutas críticas reconocidas de rm y rmdir, como rm -rf / o rm -rf ~. Rutas críticas explica qué les sucede en cada modo de permisos.

El modo automático también impulsa a Claude a seguir trabajando sin detenerse para hacer preguntas aclaratorias, aunque Claude sigue preguntando cuando tu prompt o un skill dependen explícitamente de ello. Para obtener un comportamiento autónomo más fuerte en un modo que aún te pide permiso, configura el estilo de salida Proactive en su lugar.

[!WARNING]

El modo automático reduce las solicitudes de permiso, pero no garantiza la seguridad. Úsalo para tareas en las que confíes en la dirección general, no como sustituto de la revisión en operaciones sensibles.

El modo automático solo está disponible 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 configurando permissions.disableAutoMode como "disable" en la configuración administrada.
• Modelo: en la API de Anthropic y en Claude Platform on AWS, Claude Opus 4.6 o posterior, Sonnet 4.6 o posterior, Haiku 5.5 o un modelo Fable. En Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry y las sesiones con sesión iniciada de Claude apps gateway, solo Claude Sonnet 5 o posterior, Opus 4.7 o posterior, Haiku 5.5 y los modelos Fable. Los modelos anteriores, incluidos Sonnet 4.5, Opus 4.5, Haiku 4.5 y los modelos claude-3, no son compatibles con 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 las sesiones con sesión iniciada de Claude apps gateway.

Si Claude Code indica que el modo automático no está disponible, primero revisa 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 termina, así que inicia una nueva sesión más tarde.

Un mensaje distinto que nombra un modelo y dice que el modo automático "cannot determine the safety" de una acción significa que falló una solicitud al 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 ver las causas y qué hacer.

Si configuras defaultMode: "auto" en la configuración y una sesión de la terminal se inicia en modo Manual sin ningún error, es probable que el ajuste esté en .claude/settings.json o .claude/settings.local.json. auto no surte efecto 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 de modo de permisos.

Modo automático en Bedrock, Agent Platform o Foundry

En Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry y las sesiones con sesión iniciada de Claude apps gateway, el modo automático está disponible de forma predeterminada. Si no configuras un modo de permisos allí, las sesiones interactivas se inician en modo automático, y las ejecuciones de claude -p o del Agent SDK se inician en modo Manual, cuyo valor de configuración es default:

• Sesiones interactivas de la terminal y de VS Code: para iniciarlas en un modo de permisos distinto del automático, configura permissions.defaultMode como se describe en Iniciar en un modo de permisos diferente, o elige uno en el indicador de modo de la extensión de VS Code. En qué modo se inicia una sesión enumera las versiones de Claude Code que las inician en modo automático.
• Ejecuciones de claude -p y del Agent SDK: para iniciar una en modo automático, pasa --permission-mode auto a claude -p, o pasa permissionMode: "auto" en TypeScript o permission_mode="auto" en Python. Si no pasas ningún modo de permisos, consulta Llamadas a herramientas denegadas en ejecuciones de claude -p y del Agent SDK, que también cubre versiones anteriores de Claude Code.

En estos proveedores solo son compatibles Claude Sonnet 5 o posterior, Opus 4.7 o posterior, Haiku 5.5 y los modelos Fable. Con cualquier otro modelo, la sesión se inicia en modo Manual. El modo automático con Haiku 5.5 en estos proveedores requiere Claude Code v2.1.293 o posterior.

Para impedir que los desarrolladores usen el modo automático, configura disableAutoMode como "disable" en la configuración administrada. Esto elimina auto del ciclo de Shift+Tab, y una sesión iniciada con --permission-mode auto se inicia en modo Manual. Una sesión que ya se está ejecutando en modo automático sale de él 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 terminaba.

Revisión del clasificador del lado del servidor

En el modo automático, Claude Code puede pedirle al servidor que revise 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 se lo piden al servidor:

• Una conexión directa a la API de Anthropic: en sesiones interactivas de la terminal y en sesiones de -p, del 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. Comprueba tu tipo de sesión con estas versiones mínimas de Claude Code:
  • En sesiones interactivas de la terminal, pedírselo al servidor requiere Claude Code v2.1.271 o posterior en los planes Pro, Max, Ultra y Team. En los planes Enterprise y las cuentas de la API de Claude, esas sesiones requieren v2.1.278 o posterior.
  • En sesiones de -p, del Agent SDK, de la extensión de VS Code y de la aplicación de escritorio, pedírselo al servidor requiere Claude Code v2.1.281 o posterior
  • A partir de 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. Pedírselo al servidor de forma predeterminada requiere Claude Code v2.1.278 o posterior.
• Una sesión con sesión iniciada de Claude apps gateway: requiere Claude Code v2.1.280 o posterior
• Una sesión en la nube en un entorno alojado por Anthropic: sea cual sea tu plan, cuando la inicias desde la web, la aplicación móvil o la aplicación de escritorio con Cloud seleccionado. Las sesiones iniciadas por una tarea programada en la nube se lo piden al servidor a medida que Anthropic lo implementa.

Cuando el servidor revisa las acciones, sus veredictos deciden sobre ellas. 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 comprobaciones 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 por solicitudes al clasificador en las cuentas donde esas solicitudes se facturan.

• El servidor no da ningún veredicto para una acción: Claude Code deniega la acción en lugar de ejecutarla sin revisión. En cualquier conexión, esto ocurre cuando la respuesta termina antes de que lleguen los resultados de la revisión o los resultados llegan en un formato que Claude Code no puede leer. Un gateway o proxy de LLM que acorta las respuestas o reescribe los resultados puede causar cualquiera de los dos. En una conexión directa a la API de Anthropic, también ocurre cuando la comprobación del servidor falla para la acción, por ejemplo, por tiempo de espera agotado. The server returned no safety verdict explica el mensaje de denegación, qué sucede cuando las denegaciones se repiten y qué hacer.

  Si un hook o un mod cambia la entrada de una acción después de la revisión del servidor, Claude Code puede denegar la acción sin veredicto. En las sesiones interactivas de la terminal y de VS Code con una conexión directa a la API de Anthropic, el texto de la denegación incluye a hook changed this call's input after auto mode reviewed it. Su entrada de error explica qué hacer.

Para no pedírselo al servidor y usar siempre las propias solicitudes al clasificador de Claude Code, configura 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. Configurarla como 1 allí activa la revisión del servidor en una sesión que aún no la tiene, a menos que también hayas configurado CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. Si configuras CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 y dejas CLAUDE_CODE_AUTO_MODE_SERVER sin configurar, Claude Code también deja de pedírselo al servidor, salvo en los casos que describe Desactivar capacidades previas al lanzamiento.

Modelo clasificador predeterminado

De forma predeterminada, las solicitudes al clasificador van a Claude Sonnet 5. Si /status muestra Auto mode server como Enabled, solo se envían para las llamadas que quedan fuera de la revisión del servidor.

Busca la primera fila de esta tabla que coincida con tu sesión. Obtienes el modelo de esa fila en lugar de Sonnet 5.

Si Sonnet 5 o el modelo de ANTHROPIC_DEFAULT_SONNET_MODEL no está disponible en tu proveedor o lo excluye la política de modelos de tu organización, Claude Code usa un modelo de respaldo. Ese es el modelo de tu sesión, o un modelo Opus en una sesión de Fable.

Elige el modelo clasificador

Con Claude Code v2.1.302 o posterior, configura CLAUDE_CODE_AUTO_MODE_MODEL con un ID de modelo completo para ejecutar el clasificador en un modelo distinto del predeterminado. Los IDs de modelo completos propios de tu proveedor de nube también funcionan. Este ejemplo de ~/.claude/settings.json configura Claude Sonnet 4.6:

{
  "env": {
    "CLAUDE_CODE_AUTO_MODE_MODEL": "claude-sonnet-4-6"
  }
}

Cuando tu modelo no revisa

Si se aplican varias situaciones, guíate por la primera de la lista.

Comprueba qué modelo usó el clasificador

Desde tu shell, inicia una sesión en modo automático con --debug-file:

claude --permission-mode auto --debug-file classifier-debug.log

Haz que Claude ejecute un comando de shell que no sea de solo lectura y luego busca classifier_request_started en el registro:

• Tu modelo después de model=: la variable surtió efecto
• Un modelo distinto después de model=: busca ignoring CLAUDE_CODE_AUTO_MODE_MODEL en el registro, que indica el motivo y cualquier paso que debas seguir
• No hay ninguna línea así: lee Auto mode server en /status en el prompt de Claude Code:
  • Enabled: el servidor está configurado para revisar las llamadas de esta sesión.
  • Disabled: asegúrate de que el modo de permisos sea auto y luego haz que Claude ejecute otro comando que no sea de solo lectura.

Qué bloquea el clasificador de forma predeterminada

El clasificador confía en tu directorio de trabajo y en los remotos que estaban configurados para él cuando se inició la sesión. Un remoto agregado o redirigido 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 la infraestructura de confianza.

Bloqueado de forma predeterminada:

• Descargar y ejecutar código, como curl | bash

• Enviar datos sensibles a endpoints externos

• Despliegues 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

• Force push

• 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 un despliegue. Esto abarca un workflow de CI o una configuración de despliegue 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 fuera, y un cambio de configuración que amplía lo que publica un despliegue, como un ajuste de registro de paquetes, visibilidad, artefactos o sourcemaps. La comprobació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, tanto si ese commit o push desencadena el pipeline como si no; para superarla hay que nombrar el efecto de la ejecución, no solo el commit o el push

• 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 commit

• git commit --amend cuando el commit en HEAD no se creó en esta sesión

• A partir de v2.1.198, git commit --amend cuando ya se hizo push del commit en HEAD. No se bloquea una simple reformulación del mensaje: --amend -m sin nada nuevo en el área de preparación, sobre 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 gestor de secretos, o cambiar registros DNS o certificados TLS

• Fusionar un pull request que ninguna persona ha aprobado, aprobar el propio pull request de Claude o desactivar comprobaciones de CI

• Publicar un comentario que es en sí mismo un comando para la automatización, como atlantis apply o el /deploy o /merge de un bot

• Activar, desactivar, escalar gradualmente 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 alcanza trabajos de otros usuarios

• Crear recursos de Kubernetes que se ejecutan en todos los nodos o interceptan el tráfico del clúster, como DaemonSets y webhooks de admisión

• Shells interactivos o redirecciones de puertos hacia un destino remoto sensible

• Abrir un túnel o un reverse shell que haga accesible un servicio local desde internet pública

• Imprimir una credencial o un token activo en la transcripción o en un archivo

• Acceder a una ubicación incluida como ubicación de datos sensibles en tu entorno, copiar datos desde una de ellas o enviar datos de una de ellas a un público que la entrada excluye

• Desviar la instalación de un paquete de tu registro interno de paquetes hacia un registro público. Esto se aplica cuando un registro interno o mirror figura en tu entorno o cuando le has dicho a Claude en la conversación que existe uno

• 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. Esto incluye ejecutar un agente de terceros o un harness de evaluación con el aislamiento y la aprobación por acción desactivados, como un runner 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

• Eliminar archivos en /tmp, $TMPDIR u otro directorio compartido de uso temporal o de caché mediante comodín, glob o filtro de antigüedad en lugar de una ruta específica con nombre

• Incluir detalles sensibles en contenido enviado, subido, publicado o escrito para otras personas o sistemas compartidos, cuando tu propio mensaje no autorizó esos detalles para ese destinatario. Los cuerpos de pull requests 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 archivos internas, los nombres en clave, los datos de respuestas de API en vivo como correos electrónicos o identificadores de cuenta, y los identificadores de infraestructura cuentan como detalles sensibles. Los datos personales en vivo de una respuesta de API en el cuerpo de un pull request o un 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, sin importar la visibilidad del repositorio ni el límite de confianza

• Enviar pulsaciones de teclas al propio panel de tmux de Claude Code para controlar su propia interfaz, lo que el clasificador trata como que Claude cambia sus propios permisos o supervisión

• Comentar, eliminar o forzar que pase una prueba o aserción que protege el comportamiento de seguridad, como la autenticación, el control de acceso, la validación de entradas o el 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

• Redirigir 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 encaja con la tarea, incluso en archivos de ejemplo como .env.example

• Cambiar adó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 datos personales o confiados, y el contenido de un repositorio privado que llega a cualquier superficie pública se bloquea de la misma manera. Cuando no está establecida 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 otro repositorio u organización, hacer fork con gh repo fork o hacer push a un repositorio de terceros, a menos que hayas nombrado ese destino externo

• Que contenido de un almacén local sensible, o de un archivo cuyo nombre, ruta o tipo lo marque como sensible, entre en un commit, un push, el texto de un pull request o issue, un gist o paste, o la publicación de un paquete, a menos que hayas nombrado tanto el origen como el destino. Las transcripciones de sesiones y los registros de conversaciones, 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 usuario cuentan, y que el repositorio sea privado no lo exime

• Escribir en las transcripciones de sesiones 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 comprobaciones. 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 con raíz en una variable así. 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 con 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 terminan en /* o \* nunca llegan al clasificador: Claude Code los deniega directamente.

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

Claude Code v2.1.257 y posteriores también bloquean esto 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 propia identidad de cuenta de servicio o de nodo de la máquina
• Llegar a un host público por una ruta distinta de una solicitud directa, como un túnel, un reverse shell o una configuración de resolvedor o proxy reescrita para apuntar al exterior
• 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 VMs hermanos que Claude no inició, o al nodo bajo el contenedor, o escanearlos

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 posteriores también bloquean esto 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 pull request o issue, en un documento o en cualquier otro lugar donde el enlace se abrirá u obtendrá, cuando la propia URL lleva 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 lock files 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. No se incluye una rama no predeterminada cuyo nombre la marca como destino de despliegue o publicación, como production o gh-pages: el clasificador juzga un push allí según sus propios criterios.

  El contenido de un push se sigue comprobando con las demás reglas del clasificador, y las reglas permissions.deny aún pueden bloquear comandos de push tal como están escritos en todos los modos. La protección de ramas del propio remoto sigue aplicándose.

• Eliminar exactamente los trabajos que Claude creó antes en la misma sesión

• Leer, revisar o escribir código relacionado con la seguridad, configuraciones y modelos de amenazas 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 enumeras en environment. Esto cubre solo el flujo de datos, no las operaciones destructivas ni de credenciales sobre la 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 el 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 qué puede y qué no puede abrir una lista 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 coincida con tu solicitud se ejecutan sin solicitud de permiso, a menos que el push o el pull request caigan en la lista de bloqueados, como secretos o datos sensibles que salen del repositorio, o un pull request dirigido a otro repositorio u organización. 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 distintas de las lecturas desde rutas de red se ejecutan sin solicitud de permiso en el 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 no interactivas con -p ni en sesiones en segundo plano; allí las lecturas se ejecutan como antes.

Respondas lo que respondas, Claude sigue trabajando:

• Yes, and keep allowing any reads outside the working directories: 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, and block reads outside the working directories from now on: la lectura se rechaza, y Claude Code configura permissions.blockReadsOutsideWorkingDirectories como true en tu configuración de usuario, lo que hace que las herramientas de archivos rechacen esas lecturas en esta sesión y en todas las posteriores, y en todos los modos de permisos. Para levantar el bloqueo, elimina el ajuste de todos los archivos de configuración que lo establezcan y luego reinicia cada sesión en ejecución. Para un solo directorio en esta sesión, usa /add-dir.
• No, and ask again next time: la lectura se rechaza, y la siguiente lectura fuera de los directorios de trabajo vuelve a pedir permiso
• Yes, but ask again next time: la lectura se ejecuta, no se guarda nada, y la siguiente lectura fuera de los directorios de trabajo vuelve a pedir permiso

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 lo revise antes de desplegar", el clasificador bloquea las acciones correspondientes aunque las reglas predeterminadas las permitan. Un límite sigue vigente hasta que lo levantas 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 comprobación, así 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 deny.

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 el elemento específico que la hace peligrosa, como la rama de un force push. Nombrar solo el verbo no levanta nada, así que "puedes hacer force push" deja el bloqueo en su lugar.
• Espera que cubra una sola acción: una aprobación cubre la acción destructiva que nombraste, así que una acción posterior vuelve a bloquearse a menos que hayas otorgado la aprobación como permanente. Para dejar de aprobar un patrón habitual una acción a la vez, agrégalo a autoMode.allow.
• Algunos bloqueos se mantienen: el orden de precedencia del clasificador establece a qué bloqueos puede llegar tu aprobación. Para ejecutar un paso que no levantará, sal del modo automático y responde la solicitud de permiso.

Cuando el modo automático recurre a otra opción

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 enumera la acción en /permissions en la pestaña Recently blocked, donde puedes aprobar la acción para que Claude pueda reintentarla.
• 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 permiso. Aprobar la acción solicitada reanuda el modo automático. Consulta Umbrales de bloqueos repetidos para ver cómo se cuentan los bloqueos.
• Sin veredicto del clasificador: cuando una comprobació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 bloquea la acción sin la notificación ni la entrada en Recently blocked. Consulta Auto mode cannot determine the safety of an action 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 puede detener el turno después de diez respuestas seguidas sin veredicto. Consulta The server returned no safety verdict.
• Un cambio de modo durante una comprobación: si cambias de modo de permisos mientras hay una comprobación del clasificador 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 se pueden configurar. El contador total persiste durante la sesión y solo se restablece cuando su propio límite provoca que se recurra a las solicitudes de permiso. Claude Code no cuenta una denegación para ninguno de los umbrales cuando una comprobación de seguridad independiente del modo automático rechaza la propia solicitud del clasificador.

Una ejecución no interactiva con -p 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 la infraestructura de confianza.

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

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

[accordion] Cómo evalúa las acciones el clasificador

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 allow, ask o deny se resuelven de inmediato, con estas excepciones:
   • Las escrituras en rutas protegidas se envían al clasificador aunque coincida una regla allow. Cuando la ruta protegida es el archivo al que apunta un archivo de configuración enlazado simbólicamente, la escritura puede pedirte permiso en su lugar, como describe la lista de rutas protegidas
   • Ninguna regla allow aprueba las eliminaciones de rutas críticas reconocidas de rm y rmdir
   • Las herramientas MCP marcadas con requiresUserInteraction te piden permiso directamente aunque coincida una regla allow, y lo mismo ocurre con las herramientas de conectores que tu organización configuró como ask en las sesiones donde ese ajuste llega a Claude Code
   • Un comando de shell que lleva dominios permitidos por comando también se envía al clasificador aunque coincida una regla allow, porque una regla aprueba el comando, no sus hosts
   • Las reglas ask que coinciden con el contenido de un comando, como Bash(git push *), recurren a una solicitud de permiso
   • Una escritura que la comprobación de enlaces simbólicos resuelve a una ruta protegida te pide permiso cuando la ruta que solicitó Claude no está protegida en sí misma
   • Una lectura desde una ruta de red te pide permiso aunque coincida una regla allow
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 y la primera lectura fuera de los directorios de trabajo, que te pide permiso
   • En una sesión con revisión del clasificador del lado del servidor, los comandos de shell de solo lectura y los que se ejecutan en el sandbox esperan esa revisión y se bloquean si los marca
   • Una escritura dentro de tu directorio de trabajo que la comprobación de enlaces simbólicos resuelve a una ubicación fuera de él te pide permiso
   • Cuando Claude lee un artefacto que hizo otra persona, se aplican los casos de aprobación que se enumeran en esa sección
   • Una lectura desde una ruta de red te pide permiso
3. Todo lo demás va al clasificador, salvo las eliminaciones de rutas críticas con su manejo predeterminado. Las herramientas de conectores y las herramientas MCP con requiresUserInteraction que te piden permiso directamente en el paso 1 tampoco llegan nunca al clasificador, así 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

Un mod que instales y que maneje tool.check también puede aprobar una acción. Para los casos en los que su aprobación no supera tus reglas y hooks, consulta Ampliar los permisos con hooks.

Para saber cómo se aprueban las acciones del navegador de Claude in Chrome en la extensión de VS Code, consulta Solicitudes de permiso en sesiones de VS Code.

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

• Bash(*) o PowerShell(*) generales
• Intérpretes con comodines como Bash(python*)
• Comandos run de gestores de paquetes
• Reglas allow de Agent
• Reglas allow de Monitor, porque Claude Code ejecuta los comandos de Monitor a través del shell

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

Claude Code también ejecuta git status por sí mismo antes de un comando que descartaría trabajo sin commit, como git reset --hard o rm -rf, y le muestra al clasificador si hay trabajo preparado, modificado o sin seguimiento. Claude Code informa de los archivos sin seguimiento en esa comprobació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 el contenido de tu CLAUDE.md. Los resultados de las herramientas se eliminan de esas solicitudes, de modo que el contenido hostil de un archivo o página web no puede manipular directamente al clasificador.

Puedes anotar el resultado de una llamada con el campo classifierContext de un hook PostToolUse, 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 entrantes de las herramientas 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 y el análisis técnico en profundidad.

[accordion] Cómo maneja el modo automático los subagentes

El clasificador revisa el trabajo de los subagentes en tres momentos:

1. Antes de que se inicie un subagente, se evalúa la descripción de la tarea delegada, de modo que una tarea que parece peligrosa se bloquea al crearse.
2. Mientras se ejecuta el subagente, 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 permiso. 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 comprobación de seguridad independiente de la API rechaza la revisión, el informe se entrega igualmente, 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.

[accordion] Costo y latencia

Las solicitudes al clasificador de Claude Code pueden ejecutarse en un modelo distinto de tu selección de /model. Consulta en qué modelo se ejecutan.

En los planes Enterprise y en las 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 comprobación envía una parte de la transcripción más la acción pendiente, lo que añade un viaje de ida y vuelta antes de la ejecución. Las lecturas y las ediciones en el directorio de trabajo fuera de las rutas protegidas omiten el clasificador, así que la sobrecarga proviene principalmente de los comandos de shell y las operaciones de red. Cuando el servidor revisa las acciones como parte de las solicitudes al modelo de la sesión, no hay llamadas independientes al clasificador que contar; consulta Revisión del clasificador del lado del servidor.

El acceso a la red en el sandbox no añade 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 comprueba cada conexión con la lista aprobada sin volver a llamar al clasificador.

Permitir solo herramientas preaprobadas con modo dontAsk

Si estableces el modo dontAsk, Claude Code deniega automáticamente cada llamada a herramienta que de otro modo te pediría confirmación, aunque un mod que instalaste aún puede aprobar algunas de esas llamadas. Para comprobar qué llamadas puede aprobar un mod, consulta Extender permisos con hooks.

Claude aún ejecuta acciones que no necesitan aprobación en modo Manual, como lecturas de archivos dentro de tus directorios de trabajo y comandos Bash de solo lectura. También se ejecutan las acciones que coinciden con tus reglas permissions.allow y las llamadas aprobadas por un hook PreToolUse. Usa este modo para pipelines de CI o entornos restringidos donde predefines qué puede hacer Claude; la sesión nunca espera entrada. La barra de estado muestra ⏵⏵ don't ask on en este modo.

Claude Code deniega las llamadas que coinciden con tus reglas ask explícitas en lugar de pedir confirmación. También deniega la herramienta integrada AskUserQuestion incluso si tus reglas de permitir coinciden con ella, y hace lo mismo con las herramientas de conector que tu organización estableció en ask en sesiones donde ese ajuste 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.

Una regla de permitir o un hook PreToolUse no pueden aprobar lo siguiente:

• Las eliminaciones reconocidas con rm y rmdir dirigidas a rutas críticas, como rm -rf / y rm -rf ~
• Las lecturas desde una ruta de red

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.

Incluso en modo bypassPermissions, cada una de las acciones que ningún modo aprueba automáticamente recibe una solicitud de confirmación o una denegación, aunque puedes desactivar la solicitud de confirmación para comandos rm peligrosos. 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 interactiva con la omisión de permisos disponible, Claude Code tampoco aplica los bloqueos del modo plan. Claude sigue recibiendo instrucciones de planificar sin editar, pero una edición de archivo o un comando de shell que intente durante la planificación se ejecuta sin pedir confirmación. Las reglas ask explícitas y las eliminaciones reconocidas de rm y rmdir en rutas críticas siguen pidiendo confirmación.

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.

[!WARNING]

Use este modo solo en entornos aislados como contenedores, máquinas virtuales o dev containers sin acceso a Internet, donde Claude Code no pueda dañar su sistema anfitrión.

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 inicias una sesión interactiva con este modo habilitado, Claude Code muestra un diálogo de advertencia que te pide aceptar la responsabilidad por las acciones realizadas 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 ningún diálogo.

Una sesión en segundo plano respeta tu aceptación cuando está registrada en la configuración de usuario o en la configuración administrada:

• Si no hay ninguna aceptación registrada, claude --bg --permission-mode bypassPermissions se rechaza. Acepta primero el diálogo en una sesión interactiva.

• Si skipDangerousModePermissionPrompt está establecido solo en .claude/settings.local.json, la sesión en segundo plano se inicia con la solicitud de omisión ignorada:

  • Si se ignora --allow-dangerously-skip-permissions, bypassPermissions queda fuera de su ciclo de Shift+Tab.
  • Si se ignora --permission-mode bypassPermissions o --dangerously-skip-permissions, la sesión se inicia en modo Manual en su lugar.

  Agrega "skipDangerousModePermissionPrompt": true a ~/.claude/settings.json y luego inicia una nueva sesión en segundo plano.

En Linux y macOS, Claude Code se niega a iniciarse en modo bypassPermissions 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.

[!WARNING]

bypassPermissions no ofrece protección contra inyección de solicitudes o acciones no intencionadas. Para comprobaciones de seguridad de fondo con muchos menos avisos de permisos, use modo automático en su lugar. Los administradores pueden bloquear este modo estableciendo permissions.disableBypassPermissionsMode en "disable" en configuración administrada.

Omisión de permisos ignorada en una sesión en segundo plano

Este aviso significa que la sesión en segundo plano no encontró tu aceptación de la advertencia de omisión de permisos en la configuración de usuario ni en la configuración administrada, por lo que ignoró la solicitud de omisión hecha al inicio:

Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true

Agrega "skipDangerousModePermissionPrompt": true a ~/.claude/settings.json y luego inicia una nueva sesión en segundo plano.

claude agents muestra la advertencia de omisión de permisos que las sesiones interactivas omiten

Si claude agents muestra la advertencia de omisión de permisos aunque tus sesiones interactivas la omiten, comprueba si skipDangerousModePermissionPrompt está establecido en .claude/settings.local.json o en un archivo de --settings. Las sesiones interactivas cuentan la clave en esos archivos como tu aceptación de la advertencia, y claude agents no. Tanto si la encuentras allí como si no, acepta la advertencia para agregar la clave a ~/.claude/settings.json, donde claude agents la busca.

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.

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.

Mientras permissions.blockWritesOutsideWorkingDirectories esté activado, Claude Code rechaza las escrituras de Write, Edit y NotebookEdit en archivos de configuración en todos los modos de permisos.

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, con algunas excepciones, como:
  • Los propios git worktrees de Claude en .claude/worktrees/
  • Los propios archivos de plan de la sesión actual en ~/.claude/plans/, o en el plansDirectory que configures
  • El directorio temporal propio de una sesión en segundo plano en ~/.claude/jobs/<id>/tmp/
  • Los archivos markdown en el directorio de memoria automática del proyecto, como ~/.claude/projects/<project>/memory/, en una sesión iniciada sin --restricted
  • Los archivos markdown en un directorio de memoria de subagente, como .claude/agent-memory/, en una sesión iniciada sin --restricted
• 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
• ~/.claude/dev-mods/, o dev-mods/ en el directorio al que apunta CLAUDE_CONFIG_DIR, donde Claude guarda los mods que escribe para ti

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
• remote-settings.json, la copia almacenada de la configuración administrada por el servidor de tu organización, y los archivos de firma, sincronización y consentimiento que Claude Code guarda junto con ella, en ~/.claude o en el directorio al que apunta CLAUDE_CONFIG_DIR
• Un archivo que pasaste a --settings, --mcp-config o --agents al iniciar la sesión
• El archivo al que apunta tu archivo de configuración de usuario, de proyecto o local cuando el propio archivo de configuración es un enlace simbólico, por ejemplo hacia un repositorio de dotfiles. En los modos que enrutan escrituras en rutas protegidas al clasificador, una escritura en este archivo te pide confirmación en su lugar, incluso cuando coincide una regla de permitir. Si la ruta propia del archivo también es la de un archivo de configuración, como .claude/settings.json en otra carpeta, la escritura va al clasificador como ocurre con otras escrituras en rutas protegidas

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, tu directorio home y tu directorio de trabajo. Claude Code verifica estos comandos antes de que se ejecuten, y ninguna regla de permiso aprueba uno cuyo objetivo reconozca como ruta crítica. La verificación puede pasar por alto algunos comandos, así que no reemplaza un control del sistema operativo como el sandboxing.

Una eliminación de ruta crítica es un comando rm o rmdir cuyo objetivo Claude Code reconoce como ruta crítica. Tampoco la aprueba ningún hook PreToolUse que devuelva "allow". Una regla de permiso o un hook PreToolUse no puede aprobarla ni siquiera en los modos de permisos que omiten otras solicitudes de permiso.

[!WARNING]

Un comando que la verificación pasa por alto no recibe ningún tratamiento especial, así que cualquier cosa que apruebe comandos Bash en tu sesión puede aprobarlo sin solicitud de permiso. Eso incluye una regla de permiso, el modo bypassPermissions y el modo de aprobación automática del sandbox. La verificación se aplica a rm y rmdir, así que otros comandos aprobados también pueden eliminar rutas críticas.

Estos controles se aplican tanto si la verificación reconoce un comando como si no:

• Reglas de denegación: una regla de denegación que coincide con el comando lo bloquea, aunque un mod que instalaste aún puede aprobar algunas de esas llamadas
• Sandboxing: el sandboxing hace que el sistema operativo limite en qué rutas pueden escribir los comandos Bash. Los comandos ejecutados en el sandbox aún pueden eliminar tu directorio de trabajo
• Modo estricto del sandbox: de forma predeterminada, un comando ejecutado en el sandbox puede reintentarse fuera del sandbox, y una regla de permiso o el modo bypassPermissions puede aprobar ese reintento sin solicitud de permiso. El modo estricto del sandbox desactiva el reintento

Lo que sucede con una eliminación que Claude Code reconoce depende de tu 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
• Tu directorio home. En Windows, su nombre corto 8.3 también cuenta, como C:\Users\LONGNA~1
• Raíces de unidad de Windows y sus directorios de nivel superior, como C:\ y C:\Windows. Formas de escritura como \\?\C:\ y \\localhost\C$ cuentan como C:\
• 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

Para rutas de unidades montadas como /mnt/c o /Volumes/USB, consulta La solicitud de unidad montada.

Las verificaciones sobre el nombre corto 8.3 del directorio home y sobre las formas de escritura \\?\C:\ y \\localhost\C$ requieren Claude Code v2.1.292 o posterior.

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.

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: un script pasado con -c a sh, bash, zsh o un shell POSIX similar, como en bash -c 'rm -rf ~'.
  • Cuando el script está entre comillas dobles, el shell que lo 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 lo trata como una eliminación de ruta crítica.
  • Un script entre comillas simples que vincula $1 a un valor real, como hace sh -c 'rm -rf "$1"/*' _ {}, no se marca.

Para desactivar la verificación sobre una ruta crítica escrita directamente en un script -c, como ~, establece CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 en el entorno que inicia Claude Code.

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.

La solicitud Dangerous rm operation not ruled out

El motivo completo dice:

Dangerous rm operation not ruled out — the shell may read this command differently than it was parsed

Este motivo significa que el shell puede leer el comando de forma distinta a como lo hizo Claude Code, así que una eliminación podría estar en una parte no verificada, incluso sin que haya un rm presente. En modo auto o bypassPermissions, una denegación con esta frase proviene de la misma verificación:

This command could not be checked for dangerous rm operations: the shell may read it differently than it was parsed.

Recibes la solicitud de permiso o la denegación que recibe una eliminación de ruta crítica en tu modo de permisos, bypassPermissions incluido, aunque puedes desactivar esa solicitud en modo bypassPermissions. No puedes aprobar el comando con una regla de permiso Bash o Bash(*), el modo de aprobación automática del sandbox ni un hook PreToolUse que devuelva "allow". Lee el comando y luego aprueba la solicitud o, tras una denegación, ejecútalo en tu shell.

La solicitud de unidad montada

La solicitud de unidad montada aparece en macOS, Linux y WSL cuando un rm recursivo se dirige a una ruta de unidad montada de la lista, como /mnt/c o /Volumes/USB/build. Su motivo dice Dangerous rm operation on mounted drive path: <path>. Un objetivo /* recibe la solicitud sin el flag recursivo, ya que Claude Code lee rm /Volumes/USB/build/* como una eliminación de /Volumes/USB/build.

Incluso con una regla de permiso para rm, Claude Code maneja el comando como una eliminación de ruta crítica: una solicitud de permiso o una denegación según tu modo de permisos. Aprueba la solicitud para permitir que el rm se ejecute, o desactiva la solicitud.

Rutas que reciben la solicitud de unidad montada

Compara el objetivo de tu rm recursivo o eliminación /* con estas formas de ruta, donde cada marcador de posición como <drive> o <name> representa exactamente un segmento de ruta:

Para un rm recursivo o no recursivo sobre /Volumes, /media o /mnt en sí, ves en su lugar el motivo de ruta crítica Dangerous rm operation on critical path: <path>.

Un objetivo relativo se cuenta desde tu directorio de trabajo, así que rm -rf build mientras trabajas en /Volumes/USB se dirige a /Volumes/USB/build y recibe la solicitud.

Desactivar la solicitud de unidad montada

Para dejar de recibir la solicitud de unidad montada mientras se mantienen las solicitudes por otras causas, inicia Claude Code con CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1 en su entorno. Por ejemplo, establece la variable en tu shell e inicia claude desde él:

export CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1
claude

En una sesión iniciada de esa manera, la solicitud de unidad montada deja de aparecer para una unidad completa como /Volumes/USB y para las demás rutas de la lista. Si permites Bash(rm *), usas el modo Manual y trabajas en /Volumes/USB, entonces rm -rf build se ejecuta sin solicitud de permiso.

Una solicitud que todavía muestra Dangerous rm operation on mounted drive path significa que la variable no está llegando a la sesión:

• Variable en un archivo de configuración: Claude Code ignora la variable en el bloque env de un archivo de configuración, sea cual sea el tipo de archivo de configuración, así que establece la variable donde inicias claude
• Sesión iniciada sin la variable: vuelve a iniciar claude desde un entorno donde la variable esté establecida, ya que una sesión en ejecución no la detecta

Eliminaciones que siguen pidiendo confirmación con la solicitud de unidad montada desactivada

En modo Manual con una regla de permiso para rm, un rm sobre una ruta de unidad montada aún puede pedir confirmación, sin el motivo Dangerous rm operation on mounted drive path:

• Objetivo fuera de tus directorios de trabajo: rm -rf /Volumes/USB/other mientras trabajas en /Volumes/USB/project recibe una solicitud de permiso. Para evitar esa solicitud, agrega a la sesión un directorio que contenga el objetivo
• Objetivo con un *: rm -rf build/* recibe una solicitud de permiso. Aprueba esa solicitud para ejecutar el comando, o pídele a Claude que nombre cada objetivo sin un *
• Objetivo que es una ruta crítica: /mnt en sí y tu directorio de trabajo en sí siguen siendo rutas críticas, así que rm -rf sobre cualquiera de ellos recibe una solicitud de permiso. Aprueba esa solicitud para permitir que el rm se ejecute

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:

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.

Para ejecutar estas eliminaciones sin solicitud de permiso en modo bypassPermissions, consulta Desactivar la solicitud de eliminación de ruta crítica.

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.

El límite de tiempo se aplica en Claude Code v2.1.281 y posterior, al igual que la denegación del modo auto fuera de la terminal.

Fuera de la terminal, no recibes esa solicitud de permiso:

Dondequiera que se deniegue la eliminación, puedes leer el comando completo y ejecutarlo en tu shell.

Para cambiar lo que recibes en cada modo, establece CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT en 1:

• bypassPermissions: la solicitud de permiso de la terminal no tiene límite de tiempo, y el panel de chat de VS Code te pregunta
• auto: decide el clasificador, en la terminal, el panel de chat de VS Code, las ejecuciones con -p y las sesiones de Agent SDK

Establécela en el entorno que inicia Claude Code, como tu shell o la opción env del SDK, no en un archivo de configuración de Claude Code. Para el panel de chat, agrégala a claudeCode.environmentVariables en el settings.json de usuario del propio VS Code y luego inicia una nueva conversación:

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT", "value": "1" }
  ]
}

Desactivar la solicitud de eliminación de ruta crítica en modo bypassPermissions

Para ejecutar sin solicitud de permiso los comandos Bash rm y rmdir que se dirigen a rutas críticas en modo bypassPermissions, inicia Claude Code con CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 en su entorno. Esto requiere Claude Code v2.1.311 o posterior. Claude Code lee la variable solo del entorno de inicio y la ignora en el bloque env de un archivo de configuración. Por ejemplo, establécela en tu shell e inicia claude desde ahí:

[tab] macOS, Linux, WSL

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

[tab] Windows PowerShell

$env:CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS = "1"
claude --permission-mode bypassPermissions

[tab] Windows CMD

set CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

[!WARNING]

Con esta variable establecida, pierdes una solicitud de seguridad para las eliminaciones destructivas: un comando como rm -rf ~ puede ejecutarse sin preguntarte. Establécela solo en un entorno aislado cuyo contenido puedas permitirte perder.

Las eliminaciones se ejecutan sin solicitud de permiso solo en el propio modo bypassPermissions, no en modo plan, y solo para lo que la verificación de rutas críticas marca en las herramientas Bash y Monitor. Eso incluye los comandos que Claude Code no puede analizar por completo, que también se ejecutan sin solicitud de permiso.

Avisos de inicio sobre la solicitud de eliminación de ruta crítica

Para comprobar si CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS funciona, lee la línea que Claude Code imprime al iniciar. En una ejecución con -p, aparece en stderr. En una aplicación de Agent SDK, pasa la opción stderr para leerla. La línea dice una de estas:

• is set, so dangerous rm commands can run without a prompt: las eliminaciones pueden ejecutarse sin solicitud de permiso una vez que se han cargado la configuración administrada y los hooks de plugins. Si las eliminaciones siguen recibiendo una solicitud de permiso o una denegación, consulta Por qué la solicitud de eliminación de ruta crítica sigue activa
• has no effect in this session: las eliminaciones mantienen su solicitud de permiso o denegación habitual durante toda la sesión. Para cambiarlo, busca tu caso en Por qué la solicitud de eliminación de ruta crítica sigue activa
• has no effect while the Windows registry cannot be read for managed settings: las eliminaciones mantienen su solicitud de permiso o denegación habitual, y la variable surte efecto sin reiniciar si una lectura posterior del registro de Windows tiene éxito. Si las eliminaciones siguen recibiendo una solicitud de permiso o una denegación, consulta Por qué la solicitud de eliminación de ruta crítica sigue activa

Que falte la línea no significa que la solicitud esté activa: una aplicación de Agent SDK sin la opción stderr no ve ninguna línea, y las eliminaciones aún pueden ejecutarse sin solicitud de permiso. En otros casos, comprueba que estableciste la variable en el entorno de inicio, que la sesión puede entrar en modo bypassPermissions y que claude no está dentro de otra sesión. Algunas sesiones se inician sin la variable.

Si ves una de estas líneas y no estableciste la variable, busca dónde está establecida, como tu perfil del shell, y elimínala.

Por qué la solicitud de eliminación de ruta crítica sigue activa

Si CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS no tiene efecto y las eliminaciones mantienen su solicitud de permiso o denegación habitual, busca causas como estas:

• Otra cosa gestiona las solicitudes de permiso: un --permission-prompt-tool o un callback canUseTool de Agent SDK sin --permission-prompts none, un hook PermissionRequest con cualquier matcher, o un mod que gestiona ese evento. Quita el hook, mod, herramienta o callback y reinicia claude
• El panel de chat de la extensión de VS Code o la aplicación de escritorio ejecuta la sesión: inicia claude en una terminal, como la terminal integrada de un IDE
• Una regla cubre Bash, Edit o Read: una regla de denegación o ask que se dirige a una de estas herramientas, al iniciar o cuando Claude Code la lee durante la sesión, aunque la quites después. Quita la regla y reinicia claude. Para dejar fuera una herramienta, usa --tools en lugar de una regla de denegación
• permissions.blockReadsOutsideWorkingDirectories está activado: quita el ajuste de cada archivo de configuración que lo establezca en true y luego reinicia claude
• claude se ejecuta dentro de otra sesión: un claude iniciado desde la herramienta Bash de una sesión o desde un hook, incluso con la variable en su línea de comandos. Inicia claude desde tu propio shell. No confíes en este límite de sesiones anidadas como barrera de seguridad
• Un hook PreToolUse responde ask para una eliminación: cambia lo que devuelve el hook
• Claude Code inicia la sesión por ti: las sesiones en segundo plano, los compañeros de un equipo de agentes en paneles divididos y las sesiones que crea un servidor de Remote Control se inician sin la variable. Inicia claude desde tu propio shell
• No se puede leer la configuración administrada: Claude Code no ha leído correctamente las fuentes de tu configuración administrada. Si la configuración administrada por el servidor sigue sin cargarse, consulta Remote managed settings failed to load. Para cualquier otro fallo que no sea una consulta al registro de Windows, pide a quien administra esa fuente que lo corrija
• No se puede consultar el registro de Windows: en Windows y en WSL, la variable necesita una respuesta del registro de Windows, incluso cuando WSL no lo usa para la configuración. La consulta puede fallar durante toda la sesión en un Windows que no esté en inglés, en WSL con la interoperabilidad desactivada o en un contenedor sobre un kernel de WSL2. Si la interoperabilidad está desactivada, actívala. De lo contrario, ejecuta esas eliminaciones tú mismo

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