Referencia · Avanzado · 15 min

Modo automático de Claude Code a fondo: clasificador y reglas

Cómo decide el modo automático de Claude Code, qué bloquea, cómo enseñarle tu entorno con /auto-mode-setup o autoMode y por qué no olvidar "$defaults".

Probado con Claude Code 2.1.316 · revisado 2026-11-01

Ver los archivos en GitHub Gratis · licencia MIT

Resumen

Desde la 2.1.283-2.1.284 las sesiones interactivas de terminal y VS Code arrancan en modo automático si no configuraste otro modo. En ese modo Claude no te pide permiso para lo rutinario: un modelo clasificador aparte revisa cada acción y bloquea lo irreversible, lo destructivo o lo que sale de tu entorno.

Esta referencia explica cómo decide, qué bloquea por defecto, cómo enseñarle tu infraestructura (/auto-mode-setup, autoMode.environment), cómo endurecerlo o relajarlo (hard_deny, soft_deny, allow con "$defaults") y qué hacer con cada bloqueo. Para los modos en general y las reglas allow, ask y deny, mira la receta de permisos.

Qué es y desde cuándo es el modo por defecto

El modo automático (auto) deja que Claude trabaje sin las preguntas de permiso rutinarias. Un modelo clasificador separado revisa las acciones antes de ejecutarlas y bloquea lo que va más allá de lo que pediste, lo que apunta a infraestructura que no reconoce o lo que parece provocado por contenido hostil que Claude leyó.

Con la 2.1.283 o posterior es el modo inicial integrado de las sesiones interactivas en terminal y VS Code, en todos los planes y proveedores (el CHANGELOG lo extiende a todos en la 2.1.284). La primera vez que arranca así te muestra un aviso. No arranca en auto si pasas --permission-mode, si un archivo de configuración fija permissions.defaultMode, con claude -p o el Agent SDK (que empiezan en Manual), ni si algo lo desactiva.

En la barra de estado lo ves como ⏵⏵ auto mode on; con Shift+Tab pasas a Manual, luego acceptEdits y plan. La doc lo advierte: reduce preguntas pero no garantiza seguridad; úsalo en tareas cuya dirección general te fías.

Requisitos y «auto mode unavailable»

Está disponible en todos los planes. En Team y Enterprise viene activado y un administrador lo puede apagar con permissions.disableAutoMode: "disable" en la configuración gestionada. Necesita un modelo compatible:

Los modelos antiguos (Sonnet 4.5, Opus 4.5, Haiku 4.5, claude-3) no sirven. Si te dice que no está disponible, revisa en este orden:

1. El modelo.
2. Si algún settings tiene disableAutoMode.
3. Tu versión (claude --version).

Anthropic también puede apagarlo temporalmente desde el servidor; en ese caso la sesión sigue sin auto hasta que termina, así que abre otra más tarde. Si pusiste "defaultMode": "auto" y arranca en Manual sin error, seguramente está en .claude/settings.json o .claude/settings.local.json: desde ahí no surte efecto. Muévelo a ~/.claude/settings.json.

Cómo decide cada acción (en orden)

1. Tus reglas allow, ask y deny, con excepciones: escribir en rutas protegidas va al clasificador aunque haya un allow, ningún allow aprueba borrados de rutas críticas como rm -rf ~, y las reglas ask de contenido como Bash(git push *) siempre te preguntan.
2. Lecturas y ediciones dentro de tu directorio de trabajo: se aprueban solas, salvo rutas protegidas y la primera lectura fuera de los directorios de trabajo, que te pregunta.
3. Todo lo demás va al clasificador. Si bloquea, Claude recibe el motivo, normalmente el nombre de la regla, como [Data Exfiltration].

Al entrar en auto se suspenden las reglas allow amplias que equivalen a ejecutar cualquier código (Bash(*), intérpretes con comodín como Bash(python*), comandos run de gestores de paquetes, reglas de Agent y Monitor) y se restauran al salir; las estrechas como Bash(npm test) siguen.

El clasificador ve tus mensajes, las llamadas a herramientas y tu CLAUDE.md, pero no los resultados de las herramientas: así un archivo o una web con órdenes escondidas no lo puede manipular directamente.

Qué bloquea por defecto

El clasificador confía en tu directorio de trabajo y en los remotos que tenía configurados el repo al empezar la sesión; un remoto añadido o cambiado durante la sesión no cuenta. Todo lo demás es externo hasta que lo declares. Bloquea por defecto, entre otros:

• Descargar y ejecutar código (curl | bash).
• Enviar datos sensibles fuera.
• Despliegues y migraciones de producción, y borrados masivos en la nube.
• Conceder permisos de IAM o de repositorio.
• Force push, git reset --hard, git checkout -- ., git clean -fd o git stash drop (presume que pierdes trabajo sin commit).
• git commit --amend sobre un commit que no creó en esta sesión o ya subido.
• terraform destroy, escribir en un gestor de secretos o cambiar DNS y certificados.
• Fusionar un PR que ningún humano aprobó o desactivar CI.
• Abrir túneles hacia internet e imprimir una credencial en el transcript.

En cambio, por defecto permite subir a cualquier rama del repo en el que trabajas, incluida la principal, y crear PR; ramas con nombre de despliegue como production o gh-pages se juzgan aparte. En la 2.1.316, claude auto-mode defaults lista 72 reglas soft_deny, 16 allow y una hard_deny (Data Exfiltration).

Puedes inspeccionar el clasificador desde la terminal:

# Reglas que trae Claude Code (en la 2.1.316: 16 allow, 72 soft_deny, 1 hard_deny, 21 entradas de entorno)
claude auto-mode defaults

# Leer una regla concreta por el principio de su etiqueta
claude auto-mode defaults --label 'Git Destructive'

# Lo que de verdad usa el clasificador: tus ajustes + los valores por defecto
claude auto-mode config

# Opinión de la IA sobre TUS reglas (ambiguas, redundantes, falsos positivos)
claude auto-mode critique

# Volver a los valores por defecto (borra el bloque autoMode de ~/.claude/settings.json; pide confirmación)
claude auto-mode reset

Probamos --help, defaults, defaults --label y config; critique y reset no los ejecutamos porque escriben en ~/.claude/settings.json o consumen el plan.

Enséñale tu entorno: /auto-mode-setup y environment

Casi todos los falsos bloqueos vienen de que el clasificador no conoce tu infraestructura: tu organización de GitHub, tus dominios internos, tu bucket. Hay dos formas de enseñárselo.

La guiada: /auto-mode-setup. La 2.1.304 trae la versión que también funciona en Bedrock, Vertex, Foundry, gateways y sin telemetría. Lee el CLAUDE.md, README, archivos de configuración y remotos git del proyecto, tus ajustes autoMode y permissions.allow, y los hosts, buckets y comandos de tus sesiones recientes (nunca tus mensajes); opcionalmente, la primera palabra de tu historial de shell y los remotos de tus repos. Te enseña un borrador que aceptas o descartas entero y lo guarda en ~/.claude/settings.json. No lo ejecutamos para esta referencia, porque escribe en la configuración del usuario.

La manual: el array autoMode.environment, con frases en prosa, como se lo explicarías a alguien nuevo («Source control: github.com/mi-org and all repos under it»). Empieza por tu organización de control de versiones y tus servicios clave; añade dominios y buckets cuando aparezcan bloqueos. Después, claude auto-mode config para comprobar que tus entradas están dentro.

hard_deny, soft_deny, allow y el peligro de olvidar "$defaults"

Además de environment hay tres listas, también en prosa:

La intención explícita cuenta solo si tu mensaje describe exactamente la acción y su objetivo: «limpia el repo» no autoriza un force push; «haz force push de esta rama» sí.

Lo crítico: si escribes cualquiera de las listas sin la cadena literal "$defaults", sustituyes toda la lista por defecto. Un soft_deny sin $defaults elimina las reglas de force push, curl | bash, despliegues de producción y saltarse el modo automático; un hard_deny sin $defaults elimina la regla de exfiltración de datos. Pon siempre $defaults salvo que vayas a asumir la lista entera, copiándola antes con claude auto-mode defaults.

Ejemplo para ~/.claude/settings.json: tu entorno y tus reglas, conservando las de fábrica:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/mi-org and all repos under it",
      "Trusted internal domains: api.staging.mi-empresa.com",
      "Key internal services: GitHub Actions for CI"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

El clasificador solo lee autoMode desde ~/.claude/settings.json, la configuración gestionada o --settings; nunca desde .claude/settings.json ni .claude/settings.local.json, para que un repo no pueda colarse sus propias excepciones.

Cuando bloquea: Recently denied, reintentos y límites de 3 y 20

Cada bloqueo sale como aviso (por ejemplo bash denied by auto mode · [Data Exfiltration] · /permissions) y queda en /permissions, pestaña Recently denied: resalta la acción para leer el comando y pulsa r para marcarla y reintentar al salir del diálogo. La pestaña Auto mode del mismo diálogo (desde la 2.1.246) permite ver y editar reglas y entradas de entorno sin abrir archivos; lo que cambies se guarda en ~/.claude/settings.json.

Si el clasificador bloquea 3 veces seguidas o 20 en total, el modo automático se pausa y vuelve a preguntarte; aprobar la acción lo reanuda. Esos umbrales no se configuran. Los límites que dices en la conversación («no hagas push hasta que revise») también los respeta, pero no se guardan como reglas y pueden perderse al compactar: para algo duradero usa ask o deny. Por ejemplo, un control humano antes de cada push o PR, sin salir de auto para lo demás:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

Subagentes, coste y modelo del clasificador

Con subagentes, el clasificador revisa tres veces: la descripción de la tarea antes de lanzarlo, cada acción mientras trabaja (con las mismas reglas que la sesión principal; el permissionMode de su frontmatter se ignora) y su trabajo e informe final, que llega con un aviso de seguridad si algo le pareció mal.

Coste: en Enterprise y con la API de Claude, Bedrock, Vertex o Foundry, las llamadas al clasificador cuentan en tu consumo de tokens, salvo cuando la revisión la hace el servidor (fila Auto mode server en /status). Lecturas y ediciones en tu directorio no pasan por el clasificador, así que el gasto extra viene de comandos de shell y red.

Por defecto el clasificador usa Claude Sonnet 5; desde la 2.1.302 puedes elegir otro con la variable CLAUDE_CODE_AUTO_MODE_MODEL. Si quieres que revise todos los comandos de shell, incluso los que aprueban tus reglas estrechas, activa autoMode.classifyAllShell: más cobertura a cambio de más latencia. Y recuerda: /rewind no deshace lo que se hizo con Bash; haz commit antes de tareas largas.

No empezar en auto, o quitarlo del todo

Son dos archivos distintos. Para empezar siempre en Manual (puedes seguir pasando a auto con Shift+Tab), en ~/.claude/settings.json:

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

Para quitar el modo automático por completo (las organizaciones, en la configuración gestionada):

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

Y para revisar todo comando de shell y apagar /auto-mode-setup:

{
  "autoMode": {
    "classifyAllShell": true
  },
  "skillOverrides": {
    "auto-mode-setup": "off"
  }
}

Qué comprobamos

El 1-nov-2026 en Linux con Claude Code 2.1.316, sin cambiar nada del usuario: claude auto-mode --help, claude auto-mode defaults (16 allow, 72 soft_deny, 1 hard_deny, 21 entradas de entorno), defaults --label 'Git Destructive' y claude auto-mode config. Una sesión interactiva en una carpeta de confianza arrancó mostrando ⏵⏵ auto mode on (shift+tab to cycle). No ejecutamos /auto-mode-setup, la pestaña Auto mode de /permissions ni claude auto-mode critique o reset, y no provocamos un bloqueo real del clasificador. El resto sale de la documentación oficial: modos de permisos, configuración del modo automático, comandos, checkpoints y el CHANGELOG.

Preguntas frecuentes

¿En qué se diferencia de bypassPermissions?

Los dos corren sin preguntar, pero auto pasa lo no rutinario por el clasificador y respeta deny y ask; bypassPermissions no revisa nada y solo debe usarse en contenedores o máquinas virtuales aisladas.

¿Puedo dejar el modo automático configurado en el repo para todo el equipo?

No: defaultMode: "auto" y el bloque autoMode se ignoran en .claude/settings.json y .claude/settings.local.json. Cada persona lo pone en su ~/.claude/settings.json, o la organización en la configuración gestionada.

Dice «auto mode unavailable for your plan», ¿tengo que pagar más?

Según la doc actual está en todos los planes. Revisa el modelo (los antiguos no son compatibles), si algún settings tiene disableAutoMode y tu versión. Si Anthropic lo apagó en el servidor, prueba en una sesión nueva más tarde.

¿Plan mode o auto mode?

No compiten: plan mode no edita tu código hasta que apruebas el plan; con auto mode disponible, en plan también se ejecutan los comandos que aprueba el clasificador. Lo normal es planificar en plan y ejecutar en auto.

¿Me protege de la inyección de instrucciones?

Ayuda: el clasificador no ve los resultados de las herramientas y una sonda del servidor marca contenido sospechoso. Pero la doc es clara: no garantiza seguridad. Para lo que nunca debe pasar, reglas deny o hooks.

¿Por qué me bloquea un git push a mi propio repo de la empresa?

Si es el repo en el que trabajas, lo permite. Si subes a otro repo de tu organización, el clasificador no lo reconoce: añade «Source control: <tu-org> and all repos under it» a autoMode.environment o ejecuta /auto-mode-setup.

Toda la biblioteca