Claude Code activa el modo auto por defecto el 14 de agosto: qué cambia

Respuesta corta: a partir del 14 de agosto de 2026, el modo auto pasa 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 deja de pedirte aprobación para las acciones de rutina y un modelo clasificador aparte pasa a revisarlas. 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é cambia exactamente en Claude Code el 14 de agosto de 2026?

Cambia una cosa: el modo en el que arranca una sesión nueva. Hasta ahora, 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, ambos leídos el 11 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 está 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 el recuento dice algo que la lista por sí sola no dice: hay más de treinta categorías distintas de bloqueo, y alrededor de dos tercios aparecen marcadas como añadidas 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. Puedes imprimir tú mismo las listas de reglas vigentes en JSON ejecutando claude auto-mode defaults.

¿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 importa el 14 de agosto es cuál de los dos llega solo: el modo auto es el que pasa 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. CanvasCode, la app de Mac que ejecuta las CLIs oficiales de agente lado a lado en un solo canvas, está hecha justo para ese arreglo, y nuestra lectura honesta es que el cambio vuelve una vista de estado por agente más útil de lo que el recuento de avisos fue nunca.

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, todo lo anterior describe reglas publicadas y leídas el 11 de agosto de 2026, tres días antes de que el cambio entre en vigor, y no hemos medido 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.