Olvídate de los permisos en Claude Code sin caer en modo YOLO

Si vives con `--dangerously-skip-permissions` en Claude Code y todavía no has probado auto mode, te estás perdiendo casi toda la fluidez de YOLO con una red de seguridad real.

auto mode vs --dangerously-skip-permissions: mismo flujo, uno tiene red de seguridad

TL;DR Auto mode pone un clasificador entre Claude y tu máquina: las acciones seguras se ejecutan sin preguntar, las arriesgadas se bloquean. Es lo que --dangerously-skip-permissions debería haber sido. Yo retiré mi alias YOLO el día que lo probé.

Auto mode ya no es un research preview. Desde la v2.1.228 es el modo con el que arrancan tus sesiones nuevas en Pro, Max y Team, sin que tengas que activarlo. Aun así queda gente viviendo en --dangerously-skip-permissions (el famoso modo YOLO). Es un error: auto hace casi todo lo que hace YOLO, pero con un modelo separado vigilando cada tool call antes de que se ejecute.

Imagínalo como un guardia de seguridad. YOLO no tiene guardia, todo entra. Auto mode tiene un clasificador (un modelo aparte que elige Claude Code) que revisa cada acción y solo deja pasar las que considera seguras.

Resultado:

> Shift+Tab → modo: ⚡ auto

✓ Edit src/auth.ts
✓ Run npm test
✓ Run git commit -m "fix login"
✓ Run git push origin main
✗ Run git push --force origin main  (bloqueado: reescribe historia remota)
↪ Claude para y te cuenta por qué

Cero "(y)es" pulsados durante toda la sesión, y aún así no se te va a colar un rm -rf ni un deploy a producción.

1. Activación

En Pro, Max y Team no hay nada que activar: las sesiones nuevas arrancan ya en auto. Necesitas la v2.1.228 o superior (v2.1.233 en Windows nativo). En Enterprise, con una API key de la Console, en claude -p y en Bedrock, Agent Platform o Foundry, la sesión arranca en el modo manual y llegas a auto ciclando:

> Shift+Tab

default → acceptEdits → plan → ⚡ auto

Ciclar hasta auto ya no pide confirmación. Para dejarlo fijo en cualquier provider:

{ "permissions": { "defaultMode": "auto" } }

Ese valor solo cuenta en ~/.claude/settings.json o en los managed settings. En el .claude/settings.json del proyecto se ignora en silencio, y la sesión arranca en manual sin decirte por qué.

Requisitos exactos:

Tipo	Qué necesitas
Plan	Todos. Pro, Max, Team, Enterprise y API.
Modelo	En la API de Anthropic y en Claude Platform on AWS: Opus 4.6 o superior, Sonnet 4.6 o superior, o Fable 5. En Bedrock, Agent Platform, Foundry y sesiones del Claude apps gateway: solo Sonnet 5, Opus 4.7 o superior y Fable 5. Sonnet 4.5, Opus 4.5, Haiku y los claude-3 no valen en ningún provider.
Provider	Todos por defecto. La variable `CLAUDE_CODE_ENABLE_AUTO_MODE=1`, obligatoria entre la v2.1.158 y la v2.1.206, ya no tiene efecto.
Admin (Team/Enterprise)	Disponible por defecto. El admin lo quita con `permissions.disableAutoMode: "disable"` en los managed settings.

Si Auto te dice "no disponible" y crees cumplir todo, no es un fallo transitorio: falta uno de los requisitos, y casi siempre es el modelo.

2. Lo que el clasificador deja pasar y lo que bloquea

Pasa sin preguntar:

Edits y reads dentro de tu working directory
Instalar dependencias declaradas en lockfiles o manifests
Leer .env y mandar credenciales a su API correspondiente
HTTP read-only
Push a cualquier rama del repositorio en el que trabajas, incluida la principal

Bloquea por defecto:

curl | bash y patrones download-and-execute
Mandar datos sensibles a endpoints externos
Deploys y migraciones de producción
Borrado masivo en cloud storage
Conceder permisos IAM o de repo
Force push, borrar ramas o tags remotos, reescribir historia
Push a una rama cuyo nombre la marca como destino de despliegue (production, gh-pages)
Borrar archivos que existían antes de la sesión

El push a la rama principal dejó de bloquearse en la v2.1.211. Lo que sigue revisándose es el contenido: un secreto que entra en el commit, o un cambio que expondría datos al ejecutarse el pipeline, se bloquea en cualquier rama.

Para ver las reglas completas: claude auto-mode defaults.

El clasificador ha sumado reglas desde entonces. Para las tres protecciones más recientes (git destructivo local, un rm -rf sobre una variable sin resolver y la manipulación del transcript de la sesión), ver Ahora Claude Code auto mode te protege de ti mismo.

3. La feature oculta: barreras en conversación

Esto no aparece en el release note y es lo más útil de Auto mode después del clasificador.

Si en cualquier momento dices "no hagas push" o "espera a que revise antes de deployar", el clasificador trata esa frase como una deny rule durante el resto de la sesión. Re-lee el transcript en cada check.

Tú: estamos a viernes, no me toques producción esta tarde
Claude: entendido.

[horas después, Claude propone un deploy]
✗ Run aws ecs update-service ... (bloqueado: usuario pidió no tocar prod)

Cuidado con el context compaction: las barreras viven en el transcript. Si compactas y se pierde el mensaje, la barrera desaparece. Para una garantía dura, escribe un deny rule en .claude/settings.json.

4. La feature oculta 2: drop automático de allow rules amplias

Si tienes en tu settings.json reglas tipo Bash(*) o Bash(python*) —el atajo perezoso clásico— al entrar en Auto mode Claude las descarta automáticamente. Las restaura cuando sales.

allow:
  Bash(*)              # ⚠️ se descarta al entrar en Auto
  Bash(npm test)       # ✓ esta sí se mantiene (es específica)
  Agent(my-agent)      # ⚠️ también se descarta

Lo hace porque una regla Bash(*) deshabilitaría al clasificador de facto. Las reglas estrechas (Bash(npm test), Bash(git commit *)) sí se mantienen — esas son intencionales.

5. Cuándo Auto se rinde

Si el clasificador bloquea 3 acciones seguidas o 20 totales, Auto pausa y vuelves al flujo manual. No es configurable. Si te pasa con frecuencia, es que al clasificador le falta contexto sobre tu infraestructura: se lo das declarando tus repos, buckets y dominios en autoMode.environment. Esas entradas, y las reglas propias que puedes escribir junto a las de fábrica, en Auto mode en Claude Code: escribe tus propias reglas en una frase.

Y si te levantas de la mesa mientras Claude trabaja, esa pausa pesa el doble: activa el aviso al móvil para enterarte en el momento y no al volver.

6. Cuándo aún tiene sentido YOLO

--dangerously-skip-permissions sigue teniendo un nicho (y un fallo silencioso en headless que conviene conocer antes):

Containers efímeros sin internet
VMs aisladas / sandboxes
CI con scope acotado donde quieres velocidad pura

En tu máquina principal, no hay razón para seguir en YOLO si tienes acceso a Auto. Auto te da el 95% del flow sin el riesgo.

¿Y si quieres ejecutar sin prompts en tu propia máquina pero sin depender de un clasificador? El sandbox a nivel de SO es la otra red: una valla que pone el sistema operativo.

Auto vs YOLO

	`auto`	`bypassPermissions` (YOLO)
Prompts	No	No
Clasificador antes de cada acción	✓	✗
Bloquea force push, mass delete, prod deploys	✓	✗
Honra "no hagas push" en chat	✓	✗
Drop de allow rules amplias	✓	✗
Coste por sesión	Igual en Pro, Max y Team	Igual al normal
Recomendado en máquina host	✓	✗ (solo containers)

Las llamadas del clasificador no consumen tus límites en Pro, Max ni Team. Sí cuentan como tokens en Enterprise y en las cuentas que usan la API de Claude, Claude Platform on AWS, Bedrock, Agent Platform o Foundry. Lo que sí notas siempre es la latencia: cada comprobación añade una ida y vuelta antes de ejecutar, y solo la sufren los comandos de shell y las operaciones de red.

Yo usaba YOLO con un alias claude-yolo desde hace meses. Cuando salió Auto lo probé pensando que el clasificador me iba a cortar el ritmo. Apenas se nota: en tareas largas se mete una vez cada veinte acciones, y cuando lo hace casi siempre tiene razón. El alias sigue ahí. Ya no lo uso.

Para el desglose completo de los 6 modos, ver Controla cuánta autonomía le das a Claude Code con los 6 modos de permisos. Para entender cómo se combinan modos con /permissions, ver 3 cosas que debes saber sobre /permissions en Claude Code.

Docs oficiales: Permission modes | Auto mode engineering blog (Anthropic)