Claude Code en auto mode: cómo usarlo sin que te borre la rama equivocada

Qué es el auto mode y por qué te importa ya

Llevas meses dándole a Aprobar como si fuera el like de Instagram. Claude Code te pide permiso, tú dices que sí, y a la hora número dos ya no lees el comando: solo cierras el modal. Según el blog de Anthropic sobre auto mode en Claude Code, el 97 % de las solicitudes de permiso manuales se aprueban. Eso no es supervisión. Es teatro de seguridad con el dedo en piloto.

Desde el 14 de agosto de 2026, en planes Pro, Max y Team el auto mode es el modo por defecto. Cada llamada a herramienta pasa por un clasificador que intenta cortar acciones irreversibles, destructivas o que apuntan fuera del entorno. Si bloquea, Claude busca otra vía o te pide permiso. Tras tres bloqueos seguidos o veinte en la sesión, vuelve a aprobaciones manuales. El gasto extra de tokens del clasificador, desde el 7 de agosto de 2026, ya no lo pagan esos planes.

La promesa del blog es clara: menos fatiga, más PRs y menos hostias graves. La trampa está en cómo lo usas tú. Un automatismo sin graduación es el mismo error que meter un control de seguridad a pelo en producción: o no filtra nada útil, o te pisa tráfico legítimo, o te deja creer que ya no hace falta mirar.

Qué resuelve (y qué no)

Resuelve el cuello de botella real del coding agent: tú. En un estudio controlado con 1.053 testers remunerados que describe Anthropic, el modo automático bloqueó el 89 % de los comandos peligrosos; la revisión humana solo pilló el 13,6 %. La atención humana cayó del ~17 % inicial al ~5 % tras 50 avisos. El clasificador se mantuvo estable. En sesiones reales, los daños graves no deseados (gravedad ≥7) bajaron de 6,3 % de las sesiones en manual a 2,4 % en auto. Equipos en Adobe, Nuro, Gusto y Garner Health reportan del orden de un 25 % más de PRs con auto como default en producción.

Eso no convierte al clasificador en infalible. Un 11 % de comandos peligrosos pasó en el estudio. El sistema, además, se auto-degrada a manual cuando se atasca. Y en Enterprise o socios de nube (AWS, Google Cloud, Microsoft) auto sigue siendo opcional salvo que un admin lo active por configuración gestionada.

Lo que el blog no te regala es el modelo mental para convivir con un agente que escribe, refactoriza y, si se lo pides en caliente, borra.

Paso cero: el worktree aislado antes de encender nada

Antes de tocar configuración, hay un seguro que todo lo demás presupone y nadie dice explícitamente: trabaja siempre en un git worktree aislado con commits frecuentes.

Por qué importa: si el clasificador falla ese 11 % y el agente ejecuta algo destructivo, la diferencia entre "tarde perdida" y "git reset --hard de treinta segundos" es que hayas aislado la sesión de auto mode de tu rama principal. Un worktree dedicado significa que el desastre queda contenido; un commit cada pocos minutos significa que el punto de restauración está ahí sin que tengas que buscarlo.

El checklist más adelante dice "rama o repo donde un borrado no te tumbe la semana". Aquí está el cómo operativo:

# Crea un worktree limpio para la sesión de auto mode
git worktree add../mi-repo-auto origin/main
cd../mi-repo-auto
# Trabaja aquí; main queda intacto

Haz commits pequeños y frecuentes mientras el agente trabaja. Si algo sale mal, git reset --hard o git checkout te devuelve al estado anterior sin drama. Si todo sale bien, cherry-pick o merge al árbol principal con revisión humana.

Este no es un truco de avanzados: es la primera línea de defensa real. El clasificador es la segunda.

Requisitos y qué te cambia al abrirlo

Necesitas Claude Code con plan Pro, Max o Team para el default nuevo. Si ya tenías otro modo configurado, Anthropic indica que recibirás una única pregunta para cambiar; si tenías un valor fijado, no te mueven. En Enterprise o despliegues vía nube, mira la config gestionada del admin: puede que auto ni esté encendido.

No constan en las fuentes consultadas el flag exacto tipo claude --no-auto ni la ruta de menú paso a paso para forzar el default. Lo operativo que sí está escrito: hay pregunta única al migrar, y los admins pueden imponer default por configuración gestionada.

Mientras estés en auto, cualquier regla de permiso amplia que regale ejecución de código arbitrario (el clásico python:* y primos) se aparta para que nadie se salte el clasificador. Esas reglas vuelven al salir de auto. Si tu flujo dependía de whitelists gordas, el día del cambio te va a doler: no es un bug, es el diseño.

Cómo se comporta el clasificador en la práctica

Piensa el clasificador como el portero de la discoteca del repo: no entiende tu arquitectura mejor que tú, pero sí tiene lista de gestos que huelen a incendio. Cada tool call paga unos pocos tokens de peaje (gratis para Pro/Max/Team desde el 7 de agosto de 2026, según Anthropic). Si el veredicto es peligroso, corta; Claude reintenta por el lado seguro o te devuelve el volante.

Evaluación que reporta la compañía: red-teaming interno y externo, inyección de prompts y análisis de sesiones reales. En esas métricas, auto igualó o superó la revisión manual. Úsalo como dato de producto, no como certificado de que tu monorepo es indestructible.

Tres consecuencias prácticas:

1. El clic ciego deja de ser el modo default de fallo. El humano se duerme; el clasificador no baja al 5 % de atención.
2. Sigue habiendo agujeros. 89 % no es 100 %. Lo que pase el filtro llega sin el ritual del "¿seguro?".
3. El sistema te devuelve el volante cuando duda demasiado. Tres bloqueos seguidos o veinte en la sesión no son "el agente se volvió cauto": son "ahora toca leer otra vez".

El sesgo aditivo: por qué te llena de basura... hasta que le pides fuego

Aquí entra el material que el blog de Anthropic no te va a contar como tesis de producto. Un LLM de código casi nunca borra por iniciativa propia. Borrar es la acción con más riesgo percibido y menos recompensa observable: no pone verde un test nuevo y, si se equivoca, rompe algo que no ve. Conservar sale "gratis" en su función de coste. Resultado: shims, reexports, carpetas _legacy, enums con estados fantasma y el # noqa justo encima del cadáver.

Eso es el sesgo aditivo del agente. En auto mode no desaparece: se acelera. El agente sigue prefiriendo añadir capas "por si acaso" mientras el clasificador vigila lo destructivo. El repo engorda con cortesía.

La otra cara es peor y es la que justifica el título: si le ordenas borrar sin barrera de confirmación, puede borrar. El auto mode quita justo el paso humano que antes frenaba un rm, un reset agresivo o una limpieza de módulo mal enfocada. El sesgo aditivo no es un candado mágico; es un hábito estadístico. Una instrucción positiva del estilo "el criterio de hecho incluye que el módulo viejo ya no existe en el árbol" empuja a retirar de verdad. Sin esa orden, conserva. Con esa orden y sin modal de permiso, ejecuta.

Reglas operativas que sí funcionan en el día a día con agentes:

• Declara la retirada como entregable, no como efecto colateral.
• Borra de verdad; no comentes ni aparques en _legacy importado (eso es código vivo con disfraz).
• Al retirar un pipeline, inventaría lecturas y escrituras: las escrituras gritan; las lecturas callan hasta que alguien pide un dato que ya "estaba".
• Los estados de enum que nadie escribe se eliminan del enum; "reservado" es deuda con corbata.
• Mantén F401/F841 vivos y audita los # noqa: cada supresión justifica o se va. Un vulture en modo aviso (no como gate ciego) y un test que obligue a que cada valor del enum se escriba al menos una vez cazan el cementerio elegante.

Auto mode no sustituye eso. Solo cambia quién pulsa el interruptor cuando la limpieza se pone seria.

Despliega auto de forma gradual: no es un interruptor único

El error más común es tratar auto mode como un toggle para todo el repo. Hay una distinción que lo cambia todo: el riesgo no es uniforme por tipo de tarea.

Para lectura de archivos, análisis de código y refactors no destructivos, auto mode sin restricciones añade fricción cero y riesgo casi cero. Para lo realmente irreversible (borrados, force push, cambios de esquema, operaciones sobre credenciales) la aprobación manual explícita sigue siendo la línea correcta.

Esto no es "desconfía del clasificador": es calibrar la supervisión donde duele, no donde no duele.

La forma práctica de implementarlo pasa por los pre-tool-use hooks nativos de Claude Code. Estos hooks interceptan cada tool call antes de que se ejecute y pueden vetarla sin que el clasificador sea tu única barrera. Un hook concreto para bloquear force push:

#.claude/hooks/pre-tool-use.sh
# Intercepta git push --force antes de que llegue al clasificador
if echo "$TOOL_INPUT" | grep -q "force"; then
 echo "BLOCK: force push requiere aprobación manual" >&2
 exit 1
fi

Esto es mucho más fiable que confiar en que CLAUDE.md lo frene o que el revisor de PR lo pille a posteriori. Los hooks cortan en el punto de ejecución, no en la narrativa. Ponlos primero en las acciones que de verdad no tienen marcha atrás; el clasificador hace el trabajo pesado en el resto.

La tabla de fases actualizada, sin inventar flags que no existen:

Fase	Qué haces en el repo	Qué miras
Solo lectura / refactor seguro	Auto sin restricciones en tareas no destructivas	Que el agente no derive hacia acciones fuera del perímetro
Acciones reversibles con worktree	Auto en worktrees o ramas tirables; diffs revisados	Falsos seguros: moves, chmod, scripts fuera de ruta
Irreversibles	Aprobación manual explícita siempre, reforzada con hooks	Cero excepciones: borrados, force push, esquema, credenciales

Cuando el sistema vuelva a permisos manuales tras bloqueos, lee: no es ruido, es la señal de que el agente se ha atascado en algo que merece tu atención.

Para subir el umbral de las acciones que dejas en auto, usa una métrica medible: número de sesiones sin reversión manual necesaria, o cero incidentes de gravedad ≥7 (el mismo criterio que usa Anthropic en su estudio) en N sesiones consecutivas. Sin ese criterio, la graduación es decorado.

El sistema open source AI Team OS, construido sobre Claude Code, enseña la intuición correcta en otra dirección: una capa que heredan todos los agentes con líneas rojas anti-destructivas y bloqueo de commits sobre la rama activa de otro agente (repositorio AI-company). Da igual el producto: la autonomía sin política heredada es un free-for-all con syntax highlight.

Sandboxing de credenciales: lo que más puede doler

Ni una línea de este artículo habría importado si el agente corre con acceso a producción.

Ese 11 % de comandos peligrosos que pasa el clasificador no es solo "puede borrar un archivo". Si el entorno donde corre auto mode tiene credenciales de producción, acceso a bases de datos reales o tokens con permisos amplios, el radio de blast de ese 11 % deja de ser un git reset y pasa a ser un incidente.

La regla es simple: el entorno del agente no debería ver lo que no necesita para la tarea. En la práctica:

• Credenciales de producción fuera del entorno de desarrollo donde corres Claude Code.
• API keys con permisos mínimos para lo que el agente necesita hacer, no keys maestras.
• Si usas Claude Code en Enterprise, la guía de seguridad de Anthropic recomienda límites de gasto por usuario (1.000 USD como punto de partida estándar, validado en producción) precisamente para detectar comportamientos anómalos en flujos agentivos antes de que escalen.

El clasificador es bueno frenando acciones destructivas de código. No es un firewall de red ni un gestor de secretos. Ese trabajo lo hace la arquitectura del entorno, no el modelo.

Trampas reales cuando quitas el modal

Fatiga 2.0. Dejas de ver permisos y asumes que "si el clasificador calla, es bueno". El estudio de Anthropic demuestra que el humano se duerme con avisos; tú también te duermes sin ellos. Cambia el ritual: menos clics, más lectura de diff y de plan antes del "sigue".

CLAUDE.md que se ignora. En Hacker News, un usuario reportó que Claude Code a veces se salta instrucciones del CLAUDE.md. No está documentada una relación causal con auto mode en las fuentes consultadas; es relato de usuario. Aun así, la consecuencia es obvia: si tu línea roja solo vive en prosa del markdown y el agente actúa sin pedir confirmación, una omisión duele más. Replica las líneas rojas en hooks nativos, CI y permisos estrechos, no solo en texto educado.

Whitelists anchas que desaparecen en auto. Si tu productividad secreta era python:*, en auto esa puerta se cierra a propósito. Reabre el flujo con permisos mínimos fuera de auto, o acepta el peaje del clasificador.

Limpiezas "de higiene" en caliente. "Elimina el módulo viejo y todo lo que lo toque" es la frase preferida del arrepentimiento. En auto, parte esa orden: inventario → plan en archivo → borrado por lotes con tests verdes entre medias. El historial de git es el archivo; no necesitas un santuario _old importado desde producción.

Creer que el 25 % más de PRs te absuelve del review. Más throughput es real en los datos de empresas que cita Anthropic. También es más superficie para colar el shim eterno y el enum zombie. Mide PRs y deuda que entra (noqa nuevos, rutas legacy, cobertura de borrado efectivo).

Checklist para usarlo sin regalarte el repo

1. Worktree aislado primero. Crea un worktree dedicado y haz commits frecuentes. Un desastre de auto mode es un git reset --hard, no una tarde perdida.
2. Confirma plan y si te saltó la pregunta única de migración; en Enterprise, pregunta al admin antes de asumir el default.
3. Aísla credenciales: el entorno del agente no ve keys de producción ni tokens con permisos amplios. Permisos mínimos para la tarea concreta.
4. Pon hooks nativos (pre-tool-use) en las acciones irreversibles reales: borrados, force push, cambios de esquema. Esto es la primera línea de defensa, no CLAUDE.md.
5. Quita permisos tipo "ejecuta lo que sea" y deja que el clasificador trabaje; no intentes outsmartarlo con wildcards.
6. Usa auto sin restricciones en tareas de solo lectura y refactor no destructivo. Mantén aprobación manual explícita solo para el subconjunto que de verdad no tiene marcha atrás.
7. Define el criterio para ampliar el perímetro de auto: N sesiones consecutivas sin reversión manual, o cero incidentes de gravedad ≥7. Sin criterio medible, no hay graduación real.
8. Toda retirada de código se pide como entregable verificable ("el módulo X no existe; el test Y falla si reaparece").
9. Cuando el sistema vuelva a permisos manuales tras bloqueos, lee: no es ruido, es la degradación de seguridad del producto.
10. Revisa PRs con ojo de cementerio: código muerto cortés, no solo features nuevas.

Si orquestas varios agentes sobre el mismo árbol, el problema deja de ser solo el clasificador y pasa a ser el contexto compartido: no se pisen ramas ni memoria. Ahí encaja el mismo criterio que en cómo orquestar agentes de IA sin que se pisen el contexto ni te fundan en tokens. Y si confundes "el modelo hizo algo raro" con "el modelo despertó", vuelve a fallos de especificación y perímetro, el mismo género de lectura que en Claude no se rebeló: fue un fallo de alcance.

Cierre

Auto mode gana al humano que aprueba el 97 % de los modales sin leer. Bienvenido sea. El error es leer el blog de Anthropic como si el clasificador cerrara el expediente de la responsabilidad. El agente sigue siendo aditivo por defecto y destructivo bajo orden. Trátalo como lo que es: un control nuevo sobre tráfico vivo. Worktree primero. Hooks en lo irreversible. Auto abierto donde no duele, manual donde sí. Y el merge, lo firmas tú.

Preguntas frecuentes

¿Claude Code pone auto mode por defecto para todos los planes?

No. Según el blog de Anthropic, auto mode pasa a ser default en Pro, Max y Team a partir del 14 de agosto de 2026. En Enterprise y en socios de nube (AWS, Google Cloud, Microsoft) sigue siendo opcional, aunque un administrador puede activarlo por defecto con configuración gestionada. Si ya tenías un modo fijado, no te lo cambian sin más.

¿El clasificador de auto mode bloquea todos los comandos peligrosos?

No. En el estudio controlado con 1.053 testers que publica Anthropic, bloqueó el 89 % de los comandos peligrosos (la revisión humana detectó el 13,6 %). Ese 11 % que pasa es el motivo de tener hooks nativos en acciones irreversibles y credenciales aisladas del entorno del agente. El clasificador reduce el daño; no lo elimina.

¿Cómo puedo bloquear acciones irreversibles sin depender solo del clasificador?

Claude Code tiene pre-tool-use hooks nativos que interceptan cada tool call antes de ejecutarse. Un script en .claude/hooks/pre-tool-use.sh puede vetar force push, borrados en rutas críticas o cualquier patrón que no quieras que el agente toque sin aprobación explícita. Es la primera línea de defensa real, más fiable que confiar en CLAUDE.md o en revisión de PR a posteriori.

¿Por qué un agente de código deja basura y a veces borra de más?

Por el sesgo aditivo: borrar tiene alto riesgo percibido y poca recompensa en tests, así que el modelo tiende a conservar shims, legacies y # noqa. Si la retirada se pide como entregable y no hay modal de confirmación (escenario típico en auto mode), esa barrera humana desaparece y el borrado sí puede ejecutarse. Por eso conviene aislar la sesión en un worktree, hacer commits frecuentes y pedir las limpiezas como entregables verificables, no como efectos colaterales de una tarea más grande.