Anthropic presentó auto mode para Claude Code. En vez de pedir permiso por cada archivo o comando, un clasificador evalúa comportamiento destructivo, exfiltración de datos y ejecución maliciosa. Las acciones consideradas seguras continúan; las demás se bloquean o pueden pedir confirmación.
El diseño ocupa una posición útil entre aprobar cada paso y desactivar controles. Las preguntas repetidas crean fatiga: después de muchas interrupciones una persona confirma sin evaluar. Auto mode traslada esa decisión repetitiva a un modelo entrenado para la frontera.
El intercambio sigue explícito en la guía de Anthropic. El clasificador puede permitir una acción arriesgada o bloquear una inocua, y se recomiendan entornos aislados. Un modelo evaluando a otro añade una defensa, no una prueba. La función estaba disponible en Team con Sonnet 4.6 y Opus 4.6, con Enterprise anunciado para después.
El clasificador cambia el tipo de fallo en la sesión
La aprobación manual falla por fatiga: después de decenas de prompts, la persona confirma el comando sin leerlo. Auto mode falla por veredicto: el clasificador deja pasar lo arriesgado o bloquea lo inofensivo. Anthropic describe los dos lados. La pregunta operativa es qué fallo el equipo puede ver y revertir.
En un flujo largo (refactorizar un módulo, aplicar un review, subir un parche de test) la fatiga es el riesgo dominante. Ahí el modo encaja. En un repositorio con secretos, IaC de producción o acceso a datos reales, el veredicto errado cuesta más que la interrupción. En esos casos el default sigue siendo permiso explícito, o acceptEdits si el equipo solo quiere dejar de aprobar mkdir.
--dangerously-skip-permissions sigue existiendo. Auto mode todavía bloquea clases de acción (exfiltración, destrucción masiva, ejecución maliciosa) y, si el agente insiste, vuelve a pedir confirmación. Tratar los dos como equivalentes borra la ganancia de diseño.
Mide durante una semana: cuántos prompts de permiso muestra todavía la sesión, cuántas acciones bloqueó el clasificador, cuántas reabrió un humano, cuántos commits pasaron sin que nadie mirara el diff. Sin ese cuadro, "menos interrupciones" es una impresión.
Aislamiento y reglas deny quedan fuera del modelo
Anthropic recomienda un entorno aislado. El clasificador es una capa, junto al borde de red, al sandbox y a permissions.deny del repositorio. Si el agente corre en la máquina del desarrollador con credenciales de producción, un falso negativo del clasificador tiene el mismo alcance que un clic distraído.
Las reglas deny siguen valiendo en cualquier modo. Conviene escribir las obvias antes de activar auto mode: git push a main, terraform apply, kubectl contra un clúster compartido, lectura de .env fuera del directorio, curl | bash. El clasificador cubre una familia de patrones; la regla deny cubre lo que el equipo ya sabe que no quiere.
El sandbox de Bash y el contenedor son controles distintos del modo de permiso. Se pueden combinar. Un equipo que ya usa worktree o VM para el agente gana poco discutiendo el clasificador y mucho al estandarizar el aislamiento. Un equipo que enciende auto mode en el portátil con la sesión de nube abierta está apostando al modelo.
Si la organización no confía en el veredicto, disableAutoMode en managed settings saca el modo del ciclo. Eso es decisión de admin, no de hábito individual. Dejar que cada persona elija con Shift+Tab produce una flota con tres políticas.
El registro debe mostrar lo que pasó sin clic
Cuando la aprobación desaparece de la pantalla, desaparece también el momento en que un humano veía el comando. Alguien todavía tiene que reconstruir lo que hizo el agente. Transcript de la sesión, git diff por intervalo, lista de herramientas llamadas y, si existe, la pestaña de acciones recién denegadas. Sin eso, el postmortem se vuelve "Claude hizo algo".
Define qué queda registrado por defecto en el repositorio de trabajo: branch con prefijo de agente, commits pequeños, ningún force-push, ningún secreto en el transcript. Auto mode reduce la fricción para que el agente escriba; el equipo decide si eso llega a main por PR o por push directo.
La pregunta que el Tech Lead hace en el review: ¿pasaría este cambio si la persona hubiera aprobado cada herramienta? Si la respuesta depende de "el clasificador lo dejó", el PR necesita más contexto, no menos. El modo no es un argumento de calidad.
En una tarea que toca auth, pagos o una migración, vuelve a la aprobación manual aunque el resto de la semana corra en auto. Una confirmación extra en esos archivos cuesta poco frente a un falso negativo.
Quién activa el modo, quién lo apaga, en qué plan
En el anuncio, el modo llegó como research preview en Team, con Sonnet 4.6 y Opus 4.6, y Enterprise en la cola. El admin lo apaga con disableAutoMode. En el CLI el camino descrito fue claude --enable-auto-mode y el ciclo con Shift+Tab. Desktop y VS Code piden un toggle en settings antes de que aparezca en el selector.
Importa porque "el equipo ya usa Claude Code" no describe la política. Sin un default documentado, cada sesión empieza en un modo distinto. Bastan dos líneas en el README interno: modo inicial, repositorios donde auto está permitido, repositorios donde está denegado.
Los planes y los modelos cambian. Lo que no cambia es la necesidad de un dueño. Si el admin no decide, decide el default del producto. En el lanzamiento el default era lo bastante conservador como para pedir opt-in. Después el producto puede invertir eso. La política del equipo tiene que sobrevivir a la inversión.
API y sesiones -p son otro recorte: no hay humano para el fallback cuando el clasificador vuelve a bloquear. Auto mode en CI sin allowlist es un modo de fallo distinto al del portátil. Trata los dos flujos por separado.
Token y latencia entran en el costo del flujo largo
Anthropic avisó un impacto pequeño en token, costo y latencia por llamada de herramienta. En una sesión corta eso se pierde en el ruido. En un loop de horas, el clasificador es una inferencia extra por acción. Mira la factura de la semana en que se encendió el modo, no solo la sensación de que "fluyó más".
La ganancia que justifica la cuenta es una tarea larga con poca superficie destructiva: tests, refactors locales, aplicar comentarios de review, generar parches. Dejar que el agente "resuelva la madrugada solo" encima de producción cambia costo de token por un blast radius que el clasificador no limita.
Si el equipo ya paga el plan Team, el modo es otra palanca de permiso, no un producto nuevo. La conversación útil con ingeniería es prosaica: en qué repos lo encendemos, con qué aislamiento, con qué evidencia a los quince días. Sin fecha de revisión, auto mode se vuelve un default invisible.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
