Modo auto de Claude Code: el clasificador, los tiers y cada interruptor
Cómo decide el modo de permisos auto de Claude Code: el cambio con shift+tab, el clasificador client-side y server-side con su Sonnet 5 por defecto, CLAUDE_CODE_AUTO_MODE_MODEL desde 2.1.302, el orden de los tiers, las reglas de permissions, las listas autoMode.environment administradas y los cortes de 3 y 20 bloqueos — sobre fotogramas del walkthrough oficial.
El modo auto de un vistazo
- El modo auto es un modo de permisos: Claude corre sin prompts rutinarios, y antes de que se ejecuten acciones como comandos de shell o peticiones de red, un clasificador en segundo plano comprueba que se alinean con tu petición.
- Cambia con shift+tab (auto queda al final del ciclo default → acceptEdits → plan), ejecuta claude --permission-mode auto, o responde "Yes, and switch to auto mode" en un prompt de Bash (2.1.247+). Desde 2.1.283, las sesiones interactivas nuevas arrancan en auto en todos los planes.
- Las decisiones corren en orden: primero tus reglas allow/ask/deny, luego las acciones de solo lectura y las ediciones del directorio de trabajo se aprueban automáticamente, y todo lo demás va al clasificador — un segundo modelo, Sonnet 5 por defecto.
- Fija el clasificador con CLAUDE_CODE_AUTO_MODE_MODEL (2.1.302+) o elige revisión server-side o client-side con CLAUDE_CODE_AUTO_MODE_SERVER; un modelo de clasificador no disponible hace fallar las comprobaciones y las acciones quedan denegadas.
- Protecciones: 3 bloqueos consecutivos o 20 en total del clasificador pausan el modo auto y devuelven los prompts, las reglas deny siguen aplicando dentro del modo auto, y permissions.disableAutoMode elimina el modo por completo.
How auto mode works with Claude Code
CanalClaude5:42
Permission modes — Claude Code documentation
Docscode.claude.com
Los fotogramas vienen del propio walkthrough de auto mode de Anthropic — solo tarjetas animadas a pantalla completa; cada segmento a cámara fue saltado. Los datos están cotejados contra la documentación oficial de permission-modes, permissions y auto-mode-config, más la entrada del changelog 2.1.302 que introdujo CLAUDE_CODE_AUTO_MODE_MODEL.
Los fotogramas del vídeo siguen siendo propiedad de sus creadores y se incrustan aquí como documentación paso a paso, con atribución y enlaces profundos.
Activar y configurar el modo auto paso a paso
Paso 1 — Encender el modo auto
- 1
Ver lo que el modo auto reemplaza
En el modo default, el trabajo rutinario son prompts y más prompts: un npm run build pide aprobación de Bash, una descarga de docs pide aprobación de red. El modo auto reemplaza esos prompts rutinarios con un clasificador en segundo plano — antes de que se ejecuten acciones como comandos de shell y peticiones de red, un segundo modelo comprueba que se alinean con tu petición. Las reglas ask y deny siguen aplicando; lo que desaparece es el tráfico rutinario de sí/no.
Las tarjetas de prompt que el modo auto reemplaza: una aprobación de Bash para npm run build y una aprobación de fetch, cada una esperando una respuesta Sí/No. - 2
Cambiar de modo con shift+tab
shift+tab recorre los modos de permisos durante una sesión: desde auto, una pulsación aterriza en default y el ciclo corre default → acceptEdits → plan, con los modos opcionales insertados después de plan — bypassPermissions primero y auto al final. El pie siempre nombra el modo activo. Hay tres rutas más: la opción "Yes, and switch to auto mode" en un prompt de Bash (2.1.247+), el flag claude --permission-mode auto (funciona con -p), y permissions.defaultMode — que solo surte efecto para "auto" desde el ~/.claude/settings.json de nivel de usuario, un archivo --settings o ajustes administrados, nunca desde el .claude/settings.json del proyecto.
El pie de entrada nombrando el modo activo con la pista de ciclo shift+tab — auto queda al final del ciclo. - 3
Conocer el valor por defecto: las sesiones arrancan en auto
Desde Claude Code v2.1.283, las sesiones interactivas nuevas arrancan en modo auto en todos los planes (los builds anteriores lo concedían solo a Pro/Max/Team; las configuraciones HIPAA vuelven a Manual desde 2.1.285+). Una sesión en auto muestra el modo en su pie y lleva a cabo su trabajo — aquí, una tarea "Tidy up local branches" sobre Fable 5 — mientras el clasificador revisa cada acción en segundo plano. /status lista una entrada Auto mode server cuando la comprobación server-side está activa.
Una sesión de Claude Code v2.1 corriendo en modo auto: la tarea Tidy up local branches sobre Fable 5 con el pie auto mode on.
Paso 2 — Cómo decide el clasificador
- 4
Aprender el orden de decisión: reglas, tiers, clasificador
Cada acción recorre el mismo camino. Tus reglas responden primero: deny bloquea, ask pregunta, allow deja pasar. Las acciones de solo lectura y las ediciones del directorio de trabajo se aprueban automáticamente sin el clasificador. Todo lo demás cae en el reparto por tiers — solo lectura, escrituras dentro del proyecto, todo lo demás — donde las acciones rutinarias saltan el clasificador y el resto llega al diamante del clasificador, que termina en Approve o Deny.
El diagrama de decisión: tus reglas deny/ask/allow enrutan las acciones del Agent por Tier 1 de solo lectura, Tier 2 de escrituras en el proyecto y Tier 3 hacia Skip Classifier o el diamante del clasificador. - 5
Ver lo que el clasificador lee en realidad
El clasificador no recibe tu transcript. A las peticiones se les quitan los resultados de las herramientas, así que el contenido hostil de un archivo o página no puede manipularlo directamente — lo que llega es tu petición más la acción a juzgar. En el ejemplo grabado, una pregunta sobre rate limits colapsa en dos filas: WebSearch("acme API rate limits") y WebFetch(docs.acme.com). Esa es toda la superficie que evalúa el clasificador.
La franja de visibilidad del clasificador: la conversación completa reducida a las llamadas WebSearch y WebFetch que el clasificador evalúa. - 6
Por qué comandos gemelos reciben veredictos distintos
El clasificador juzga la acción, no la vibra. En la segunda franja, git branch -d old-login borra una rama local — rutina. Su gemelo, git push origin --delete old-login, borra una rama en el remoto — exactamente el tipo de acción que el reparto por tiers le entrega al clasificador en vez de dejarla pasar. Espera clasificación en todo lo que salga de la máquina o toque estado compartido, aunque suene a la misma limpieza.
Los gemelos de git: el borrado de rama local sigue siendo rutina mientras git push origin --delete sube al clasificador.
Paso 3 — Reglas y el modelo del clasificador
- 7
Elegir revisión server-side o client-side
El clasificador corre en uno de dos sitios. Server-side: Claude Code pide al servidor de modelos de la sesión que revise la acción como parte de su petición — /status muestra la entrada Auto mode server. Client-side: Claude Code envía sus propias peticiones de clasificador, usadas cuando el servidor no da veredicto o un proxy descarta resultados de revisión. Contrólalo con CLAUDE_CODE_AUTO_MODE_SERVER=1 (server) o =0 (siempre client-side); si el servidor no da veredicto, Claude Code deniega la acción en vez de ejecutarla sin revisar.
- 8
Fijar el modelo del clasificador (2.1.302+)
El clasificador usa Claude Sonnet 5 por defecto; una sesión que ya corre sobre Sonnet 4.6 usa 4.6, y se respeta ANTHROPIC_DEFAULT_SONNET_MODEL. Desde 2.1.302, CLAUDE_CODE_AUTO_MODE_MODEL fuerza un clasificador concreto — por ejemplo "env": undefined en ~/.claude/settings.json. Dos modos de fallo que conocer: un modelo no disponible hace fallar las comprobaciones y las acciones quedan denegadas, y los modelos excluidos o no soportados (Opus 5, Sonnet 5.5, Opus 5.5) caen en silencio al valor por defecto. Depura con claude --permission-mode auto --debug-file classifier-debug.log y busca classifier_request_started.
- 9
Escribir las reglas a las que el clasificador cede
Las reglas responden antes de que el clasificador llegue a correr, así que pon ahí los límites duros. El managed-settings.json grabado muestra la forma: deny: ["Bash(curl *)", "Read(./.env")], ask: ["Bash(git push *)"], allow: ["Bash(python:*)"] — comentado en el vídeo como excesivamente amplio. Una regla ask como Bash(git clean *) sigue preguntando incluso en modo auto, y los comandos Bash de solo lectura pueden esperar la revisión del clasificador en vez de preguntar. Endurece las reglas allow; el clasificador es una red de seguridad, no una excusa para Bash(*).
El bloque permissions: deny a curl y a las lecturas de .env, ask en git push, allow a python — con el allow demasiado amplio señalado.
Paso 4 — Configuración administrada y protecciones
- 10
Configurar autoMode.environment para equipos
En los ajustes administrados, autoMode.environment le dice al clasificador qué cuenta como contexto de confianza: la tarjeta grabada lista "Source control: github.com/acme and all repos under it", "Trusted cloud buckets: s3://acme-builds" y "CI server: ci.acme.internal". Con $defaults al lado, tus entradas extienden la lista integrada en vez de reemplazarla. Es la respuesta del lado del administrador a los prompts del clasificador que se disparan sobre tu propia infraestructura — nombra los repos, buckets y servicios que tu equipo usa de verdad.
La tarjeta autoMode.environment: control de fuentes de confianza en github.com/acme, los buckets s3://acme-builds y el servidor CI ci.acme.internal. - 11
Superponer allow, soft_deny y hard_deny
Además de environment, los ajustes administrados llevan tres listas de reglas: "allow" ([$defaults, "Deploying to staging is allowed"]), "soft_deny" ([$defaults, "Running database migrations"]) y "hard_deny" ([$defaults, "Never touch production custo..."]). Los patrones allow detienen las aprobaciones de una acción cada vez; los soft denies enrutan al clasificador con sesgo en contra; los hard denies acaban con la pregunta. Inspecciona las listas integradas completas cuando quieras con claude auto-mode defaults, que las imprime como JSON.
Las listas superpuestas: allow para deploys a staging, soft_deny para migraciones de base de datos, hard_deny para datos de producción. - 12
Conocer los disyuntores
El modo auto se pausa solo: 3 bloqueos consecutivos del clasificador o 20 en total devuelven el prompting normal, y ninguno de los dos números es configurable. Las palabras también actúan como señales — las frases tipo "don't push" se vuelven señales de bloqueo, y una aprobación declarada puede levantar un bloqueo cuando nombra la acción y sus detalles. Para eliminar el modo por completo, pon permissions.disableAutoMode en "disable" en los ajustes administrados; una sesión en curso sale del modo auto y lo dice. Y recuerda: las reglas deny siguen ganando dentro del modo auto.
El modelo del clasificador, en detalle
El clasificador es la pieza que más se malconfigura, porque sus valores por defecto son invisibles hasta que algo se deniega. El comportamiento de abajo está documentado en las páginas permission-modes y auto-mode-config y en el changelog de 2.1.302:
- 1Modelo por defecto: Claude Sonnet 5. Una sesión que ya corre sobre Sonnet 4.6 usa Sonnet 4.6 en su lugar, y se respeta ANTHROPIC_DEFAULT_SONNET_MODEL.
- 2Override fijado: CLAUDE_CODE_AUTO_MODE_MODEL (2.1.302+) corre el clasificador sobre un ID de modelo completo — un modelo no disponible hace fallar las comprobaciones y las acciones se deniegan, así que fija un modelo que tu plan sirva de verdad.
- 3Fallback silencioso: los modelos de clasificador excluidos o no soportados (Opus 5, Sonnet 5.5, Opus 5.5) no dan error — se usa el modelo de clasificador por defecto en su lugar.
- 4Dos runtimes: la revisión server-side viaja en las peticiones de modelo de la sesión (CLAUDE_CODE_AUTO_MODE_SERVER=1); las peticiones client-side son el fallback (=0), usadas cuando el servidor no da veredicto o un proxy descarta resultados de revisión.
- 5Nada corre sin revisión: si ningún camino devuelve veredicto, Claude Code deniega la acción — el modo auto nunca ejecuta una acción que requería revisión sin ella.
- 6Verificación: claude --permission-mode auto --debug-file classifier-debug.log registra entradas classifier_request_started, y /status muestra si el Auto mode server está activo.
De aquí vienen también los reportes de "auto mode not available for this model": la disponibilidad depende de plan, organización, modelo y proveedor, y un modelo de clasificador fijado que tu proveedor no sirva convierte cada comprobación en una denegación. Arregla la variable o quítala — el modelo de la sesión no necesita cambiar.