Claude Code activó el modo auto por defecto el 14 de agosto: qué cambió

Respuesta corta: el 14 de agosto de 2026, el modo auto pasó a ser el modo de permisos por defecto de las sesiones nuevas de Claude Code en los planes Pro, Max y Team, lo que significa que Claude Code dejó de pedirte aprobación para las acciones de rutina y un modelo clasificador aparte pasó a revisarlas. Escribimos este artículo el 11 de agosto y lo comprobamos contra la documentación oficial el 14 de agosto, el día en que entró en vigor: el cambio salió tal como se anunció, sin variación en los términos. La documentación de Anthropic afirma que un valor por defecto que hayas fijado tú se mantiene salvo que aceptes el aviso único de cambio, y que un valor por defecto gestionado por tu organización no cambia. Puedes cambiar de modo cuando quieras.

¿Qué cambió exactamente en Claude Code el 14 de agosto de 2026?

Cambió una cosa: el modo en el que arranca una sesión nueva. Hasta esa fecha, una sesión nueva de Claude Code arrancaba en modo Manual, cuyo valor de configuración es default, donde solo las lecturas se ejecutan sin aviso y toda edición de archivo u orden de terminal se detiene a esperar tu aprobación. Desde el 14 de agosto, las sesiones nuevas en Pro, Max y Team arrancan en auto, descrito en la tabla oficial de modos como que ejecuta "Everything, with background safety checks", es decir, todo, con comprobaciones de seguridad en segundo plano. El cambio está documentado en el resumen de novedades de Claude Code de la semana del 3 al 7 de agosto de 2026 y en la referencia de modos de permisos, leídos primero el 11 de agosto de 2026 y releídos el 14 de agosto de 2026.

Tres detalles deciden si esto te afecta. Si ya fijaste defaultMode por tu cuenta, tu configuración sobrevive al cambio salvo que aceptes un aviso único que ofrece cambiarla. Si tu organización gestiona el valor por defecto, no cambia nada. Y el mismo resumen registra algo que ya estaba en vigor en esos planes: las llamadas al clasificador que hace el modo auto ya no cuentan para tus límites de uso, así que la comprobación extra de seguridad no se cobra de tu cuota en Pro, Max y Team.

¿Qué sigue bloqueando el modo auto de Claude Code?

El modo auto no es una puerta abierta. Toda acción que no sea una lectura o una edición dentro de tu directorio de trabajo va a un modelo clasificador aparte que, según la documentación, bloquea lo que escala más allá de lo que pediste, lo que apunta a infraestructura no reconocida, o lo que parece movido por contenido hostil que Claude leyó. La lista publicada de bloqueos es larga y concreta: descargar y ejecutar código, como en curl | bash, despliegues y migraciones de producción, force push, conceder permisos de IAM o de repositorio, terraform destroy y sus equivalentes de Pulumi, CDK y Terragrunt, git reset --hard y las demás órdenes que el clasificador presume que descartarían trabajo sin confirmar, imprimir una credencial viva en la transcripción o en un archivo, y borrados dirigidos a la raíz del sistema de archivos o a tu directorio personal.

Contamos las categorías de esa página el 11 de agosto de 2026 y volvimos a contarlas el 14 de agosto de 2026, y las dos cuentas se sostienen: la página lista 38 elementos distintos de bloqueo, de los cuales 26, es decir el 68 por ciento, aparecen marcados como añadidos en la versión 2.1.195 de Claude Code o posterior. Esa es nuestra lectura, y puedes repetirla en la misma página. La consecuencia práctica importa más que el número: el modo auto tal como se comportaba unas versiones atrás no es el modo auto de hoy, así que un consejo sobre él escrito incluso hace un mes está describiendo otro software.

¿Qué contiene de verdad la lista de reglas del modo auto?

La página de documentación es un resumen. Las reglas con las que trabaja el clasificador las imprime un comando, y leerlas cambia lo que esperas del modo. Ejecuta esto en una terminal:

claude auto-mode defaults

El 14 de agosto de 2026, en Claude Code 2.1.232, eso devolvió cuatro listas, y no las dos que la página sugiere: 17 entradas de permiso, 66 entradas de bloqueo blando, exactamente 1 entrada de bloqueo duro, y 20 líneas de entorno. La diferencia frente a los 38 elementos de la página es granularidad, y no ocultación, porque la página agrupa reglas en viñetas de texto corrido mientras que el comando nombra cada regla por separado, y la forma nombrada es la que importa en la práctica.

Dos cosas destacan. Primera, casi toda regla de bloqueo es blanda, y cada entrada blanda lleva la instrucción de que se libera cuando NOMBRAS la acción concreta y sus detalles, lo que significa que el modo está construido para que se le argumente, no para ser absoluto. Segunda, exactamente una regla es dura, llamada Data Exfiltration, que cubre datos sensibles cruzando la frontera de confianza como resultado de una acción del agente, y su propio texto dice que se evalúa primero y que ignora las excepciones. Si te quedas con una regla del modo auto, quédate con esa, porque es la única que ninguna nominación, ninguna excepción y ninguna otra regla aparta del camino.

¿Qué aprueba Claude Code sin preguntar en modo auto?

La lista de permitidos es de donde sale la sensación diaria del modo auto, y conviene leerla antes de decidir qué opinas del cambio. Claude Code aprueba solo las operaciones locales de archivo en tu directorio de trabajo, instalar dependencias declaradas en tus archivos de bloqueo o manifiestos, las peticiones HTTP de solo lectura, leer el .env y enviar esas credenciales a la API que les corresponde, y hacer push a cualquier rama del repositorio en el que estás trabajando, incluida la rama por defecto. Abrir un pull request que se corresponde con lo que pediste también se ejecuta sin aviso.

Dos excepciones viven dentro de ese último punto y se pasan por alto con facilidad. Una rama distinta de la principal cuyo nombre la marca como destino de despliegue o de publicación, como production o gh-pages, no queda cubierta por el permiso general de push y se juzga en sus propios términos. Y el contenido de cualquier push se sigue comprobando contra todas las demás reglas, así que un destino permitido no vuelve permitido un commit que lleva un secreto. Si quieres un punto de control humano antes de los push o los pull request sin salir del modo auto, la vía documentada es añadir reglas permissions.ask, y no abandonar el modo.

¿El modo auto es lo mismo que ejecutar Claude Code con --dangerously-skip-permissions?

No, y esa distinción es lo más útil de este artículo, porque los dos se comentan como si fueran el mismo atajo. La opción --dangerously-skip-permissions pone a Claude Code en modo bypassPermissions, cuya fila en la tabla oficial de modos dice "Everything", todo, en la columna de lo que se ejecuta sin preguntar, y "Isolated containers and VMs only", solo contenedores y máquinas virtuales aislados, en la columna de para qué sirve. En ese camino no hay clasificador, mientras que el modo auto mantiene un paso de revisión delante de toda acción que no sea de lectura. Los dos se pueden fijar como modo inicial mediante permissions.defaultMode en la configuración, así que la diferencia no es que uno sea configurable y el otro no. La diferencia que llegó el 14 de agosto es cuál de los dos viene solo: el modo auto es el que pasó a ser el modo inicial de todo el mundo en Pro, Max y Team, y el bypass sigue siendo algo que tienes que buscar de forma deliberada.

Hay un detalle que vuelve concreta la diferencia en lugar de filosófica: lanzar un bucle autónomo de agente que se ejecuta sin aprobación humana y sin sandbox, con --dangerously-skip-permissions citado en la documentación como el ejemplo, está en la propia lista de bloqueos del modo auto. El modo auto impide que Claude arranque justamente aquello que se salta los permisos. Entrar en modo auto también descarta las reglas amplias de permiso que conceden ejecución arbitraria de código, incluido el Bash(*) general, los intérpretes con comodín como Bash(python*) y las órdenes de ejecución de gestores de paquetes, mientras que las reglas estrechas como Bash(npm test) se mantienen. Las reglas descartadas vuelven cuando sales del modo. Esta duda se está planteando en público ahora mismo: un hilo titulado simplemente "Dangerously skip permissions" se publicó en r/ClaudeAI el 10 de agosto de 2026, y otro titulado "Sandboxing & Powerusers: How to maintain productivity without losing security?" el 6 de agosto de 2026.

¿Cómo conservar la aprobación manual en Claude Code después del 14 de agosto?

Fija tú mismo el valor por defecto, en el archivo correcto. El modo Manual es el que revisa cada acción, aparece con la etiqueta Manual en la CLI y en las interfaces de VS Code, JetBrains y la aplicación de escritorio, y su valor de configuración es default, con manual aceptado como alias desde la versión 2.1.200 de Claude Code. Poner {"permissions": {"defaultMode": "manual"}} en tu archivo de configuración de usuario, en ~/.claude/settings.json, es lo que hace que las sesiones nuevas sigan arrancando ahí, y la documentación es explícita al decir que un valor por defecto fijado por ti sobrevive al cambio del 14 de agosto salvo que aceptes el aviso único.

A mitad de sesión, pulsar Shift+Tab recorre los modos y la barra de estado muestra cuál está activo, con Manual mostrado como una insignia gris manual mode on. Conviene conocer una asimetría si administras equipos: defaultMode: "auto" se ignora cuando aparece en el .claude/settings.json o en el .claude/settings.local.json de un proyecto, y es deliberado, para que un repositorio que clonas no pueda concederse a sí mismo el modo auto. Solo cuenta viniendo de tus propias configuraciones de usuario. En planes Team y Enterprise, un administrador puede retirar el modo por completo fijando permissions.disableAutoMode como disable en las configuraciones gestionadas.

¿Se puede impedir que Claude Code lea tus archivos de secretos?

Esa es la pregunta que un desarrollador llevó a r/ClaudeCode el 10 de agosto de 2026 bajo el título "Do you block Claude Code from reading your secrets files?", y la documentación responde de una forma que sorprende en las dos direcciones. Leer el .env y enviar esas credenciales a la API que les corresponde está en la lista de permitidos, así que el modo auto no lo va a impedir. Pero imprimir una credencial viva en la transcripción o en un archivo sí está bloqueado, y desde la versión 2.1.203 el contenido procedente de un almacén local sensible, o de un archivo cuyo nombre, ruta o tipo lo marque como sensible, queda bloqueado para entrar en un commit, un push, el texto de un pull request o de una incidencia, un gist o una publicación de paquete, salvo que hayas nombrado el origen y el destino. Las transcripciones de sesión, las claves SSH, las carpetas de credenciales de nube, los perfiles de navegador y el historial de shell cuentan todos, y que el repositorio sea privado no levanta el bloqueo.

Si quieres una garantía dura en lugar de un juicio del clasificador, el instrumento documentado es una regla de denegación. Las reglas en permissions.deny se aplican en todos los modos, incluido bypassPermissions, y ninguna configuración de modo pasa por encima de ellas. La misma página hace una observación relacionada que es fácil de equivocar: un límite que declaras en la conversación, como decirle a Claude que no haga push, lo trata el clasificador como señal de bloqueo y sigue vigente hasta que tú lo levantes, pero no queda guardado como regla. El clasificador lo relee de la transcripción en cada comprobación, así que la compactación de contexto que borre ese mensaje puede perder el límite. Un límite del que realmente dependes pertenece a una regla de denegación, no a una frase.

¿Qué pasa cuando el clasificador bloquea demasiado?

Claude Code tiene un repliegue documentado, y conocer los números evita pensar que la herramienta se rompió. Si el clasificador bloquea una acción tres veces seguidas, o veinte veces en total, el modo auto se pausa y Claude Code vuelve a pedir aprobación. Aprobar la acción que te pregunta reanuda el modo auto. Esos umbrales no son configurables. Cualquier acción permitida reinicia el contador de seguidas, mientras que el contador total persiste durante la sesión. En ejecuciones no interactivas con la opción -p no hay a quién preguntar, así que los bloqueos repetidos abortan la sesión.

Cada acción denegada muestra una notificación y aparece en /permissions, en una pestaña de denegadas recientemente, donde pulsar r la reintenta con aprobación manual. Vale ajustar la expectativa en un punto: en la mayoría de las sesiones, desde la versión 2.1.208, el motivo que recibe Claude es el texto fijo Blocked by classifier en vez de una explicación escrita, así que el agente no siempre puede decirte por qué se le impidió. La documentación lee el bloqueo repetido como falta de contexto del clasificador sobre tu infraestructura, y remite a los administradores a las entradas de repositorio, bucket y servicio de confianza, para corregirlo en el origen.

¿Qué cambia esto para quien ejecuta varios agentes de IA a la vez?

Cambia la forma de tu atención, que es la parte de la que nadie avisa. Una petición de permiso es una interrupción, pero también es un punto de control, y llega por agente. Quita las peticiones de rutina de cuatro sesiones a la vez y las cuatro corren más lejos antes de que mires ninguna de ellas. Ese es el objetivo del modo y es también el riesgo nuevo: el trabajo entre puntos de control se alargó, así que la revisión tiene que absorber lo que antes atrapaba la aprobación. Nuestra guía de cómo revisar código escrito por varios agentes de IA defiende empezar por lo que el cambio no debería haber tocado, y ese hábito se vuelve más valioso, no menos, cuando las aprobaciones dejan de llegar.

Dos comportamientos documentados importan de forma específica para el trabajo con varios agentes. Los subagentes los comprueba el clasificador en tres puntos, antes de que el subagente arranque, en cada una de sus acciones, y de nuevo sobre su historial completo de acciones cuando termina, y un permissionMode declarado en el frontmatter de un subagente se ignora, de modo que un subagente no puede aflojar las reglas a las que está sometida la sesión principal. Y el modo auto empuja a Claude a seguir trabajando en vez de detenerse a hacer preguntas aclaratorias, lo que se acumula entre sesiones paralelas. Con las aprobaciones fuera del camino, lo único que queda diciéndote dónde está cada agente es su propio estado, por sesión, que es la vista alrededor de la cual construimos CanvasCode y la razón por la que el cambio hizo que esa vista importara más de lo que nunca importó un recuento de avisos. Las sesiones también pasaron a mandarse mensajes entre sí, y la clase de modo de permisos de cada una decide si esos mensajes llegan: lo cubrimos en las sesiones de Claude Code pueden mandarse mensajes entre sí.

Dos limitaciones que no vamos a disimular. Primera, la propia documentación de Anthropic lleva una advertencia de que el modo auto reduce las peticiones de permiso pero no garantiza la seguridad, y recomienda usarlo en tareas cuya dirección general te merece confianza, y no como sustituto de la revisión en operaciones sensibles, lo que es una salvedad del fabricante, no de un escéptico. Segunda, este artículo se escribió el 11 de agosto de 2026 a partir de reglas publicadas, y se actualizó el 14 de agosto de 2026, el día en que el cambio entró en vigor, tras releer las mismas fuentes y ejecutar el volcado de reglas; lo que seguimos sin hacer es medir cómo se comporta el clasificador a lo largo de una semana de trabajo en un repositorio real, incluida la frecuencia con la que produce un bloqueo falso. En planes Enterprise y en cuentas de API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform y Microsoft Foundry, las llamadas al clasificador sí cuentan para el uso de tokens, al contrario que en Pro, Max y Team. Si tu motivo para preocuparte por el peso de la sesión es el coste, nuestra nota sobre cuándo usar /clear en lugar de /compact cubre ese lado.