Claude Code: el modo automático será el predeterminado

Qué cambia el modo automático el 14 de agosto de 2026

El modo automático de Claude Code ejecuta las llamadas a herramientas sin detenerse para pedirle confirmación y envía cada acción a un modelo clasificador independiente para revisarla primero. A partir del 14 de agosto de 2026, será el modo con el que se inicien las sesiones nuevas en los planes Pro, Max y Team. Puede cambiar de modo en cualquier momento. El valor predeterminado que ya haya configurado no se sobrescribe.

La documentación describe el cambio así:

A partir del 14 de agosto de 2026, el modo automático se convierte en el modo de permisos predeterminado para las sesiones nuevas de los planes Pro, Max y Team. Puede cambiar de modo en cualquier momento. El valor predeterminado que configure usted se mantiene, a menos que acepte el aviso de cambio único. El valor predeterminado que gestione su organización no cambia.

Dos cláusulas son más importantes que la fecha. Un defaultMode que configure en su propio archivo de configuración se mantiene después del cambio. También se mantiene el valor predeterminado que su organización implemente mediante la configuración administrada. La publicación del anuncio añade que el modo automático seguirá siendo opcional para los planes Enterprise y para las cuentas que usen la API durante la primera fase del despliegue.

Si ejecuta Claude Code en un VPS (servidor privado virtual), conviene leer sobre este cambio antes de que entre en vigor. Un aviso de permisos es un punto de control que requiere que haya una persona frente al teclado. En un sistema remoto, normalmente usted no está presente. Por eso, el modo con el que se inicia una sesión es el modo que seguirá usando durante horas.

Modos de permisos de Claude Code, de mayor a menor supervisión

Hay seis modos. El nombre al principio de cada línea es el valor que se escribe en la configuración o se pasa a --permission-mode.

• default: Claude pregunta antes de usar cada herramienta nueva. Las lecturas dentro del directorio de trabajo se ejecutan sin solicitar confirmación. La CLI (interfaz de línea de comandos) muestra este modo como Manual y acepta manual como alias desde Claude Code v2.1.200.
• plan: Claude lee archivos y ejecuta comandos para explorar, pero no modifica el código fuente. Las modificaciones permanecen bloqueadas hasta que se aprueba el plan.
• acceptEdits: las modificaciones de archivos se ejecutan sin solicitar confirmación, junto con los comandos del sistema de archivos mkdir, touch, rm, rmdir, mv, cp y sed. Esto sólo se aplica a las rutas dentro del directorio de trabajo o de additionalDirectories. Cualquier otro comando de shell sigue solicitando confirmación.
• auto: todo se ejecuta, pero el clasificador comprueba primero cada acción. Las reglas explícitas ask siguen obligando a solicitar confirmación.
• dontAsk: Claude Code deniega automáticamente cualquier acción que habría solicitado confirmación. Sólo se ejecutarán las reglas allow, los comandos Bash integrados de sólo lectura y las llamadas que apruebe un hook PreToolUse. La sesión nunca espera entrada.
• bypassPermissions: se omiten las solicitudes de confirmación y las comprobaciones de seguridad, incluidas las escrituras en rutas protegidas como .git y .claude.

Pulsa Shift+Tab durante una sesión para recorrer default, acceptEdits y plan. La barra de estado muestra el modo seleccionado, como ⏵⏵ auto mode on o un ⏸ manual mode on gris. Los demás modos no forman parte de ese ciclo de forma predeterminada. auto se incorpora cuando tu cuenta cumple los requisitos. bypassPermissions sólo se incorpora si la sesión se inició con --permission-mode bypassPermissions o --dangerously-skip-permissions. dontAsk nunca aparece en ese ciclo, así que debes configurarlo con claude --permission-mode dontAsk.

El modo automático también necesita un modelo reciente, que es la razón habitual por la que no aparece. En agosto de 2026, la documentación indica Claude Opus 4.6 o posterior, Sonnet 4.6 o posterior y Fable 5 en Anthropic API, y señala que los modelos anteriores, como Sonnet 4.5, no son compatibles con ningún proveedor. Si Claude Code informa de que el modo automático no está disponible, no se cumple uno de esos requisitos. No se trata de una interrupción temporal, por lo que esperar no lo solucionará.

Dos controles se aplican en todos los modos, incluido bypassPermissions: las reglas deny y las reglas explícitas ask. Esos son los controles que se mantienen independientemente del modo con el que se inicie una sesión.

Qué bloquea el clasificador del modo automático

El clasificador es un segundo modelo que lee la acción pendiente y decide si encaja con lo que solicitó. La documentación describe su función en una sola frase:

Un modelo clasificador independiente revisa las acciones antes de ejecutarlas y bloquea todo lo que amplíe el alcance de su solicitud, se dirija a infraestructura no reconocida o parezca impulsado por contenido hostil que Claude haya leído.

Bloqueadas de forma predeterminada, dentro de las categorías que un operador de servidores encuentra con más frecuencia:

• Descargar y ejecutar código, como curl | bash
• Despliegues y migraciones en producción
• git push --force
• Modificar infraestructura compartida
• Abrir un túnel o una reverse shell que haga accesible un servicio local desde Internet público
• Imprimir una credencial o un token activo en la transcripción o en un archivo

Permitidas de forma predeterminada:

• Operaciones con archivos locales en el directorio de trabajo
• Instalar dependencias declaradas en los archivos de bloqueo o manifiestos
• Solicitudes HTTP de sólo lectura
• Hacer push a cualquier rama del repositorio en el que está trabajando

No trabaje a partir de un resumen como el anterior. Ejecute claude auto-mode defaults para imprimir las listas completas de reglas en formato JSON y lea el conjunto incluido en la versión que tiene instalada.

Antes de basarse en este mecanismo, tenga en cuenta dos limitaciones documentadas. Primero, el clasificador ve sus mensajes, las llamadas a herramientas y el contenido de CLAUDE.md, pero los resultados de las herramientas se eliminan. Por tanto, el texto de un archivo o de una página web que Claude haya leído no puede dirigirse directamente al clasificador. Segundo, cuando el clasificador bloquea una acción 3 veces seguidas o 20 veces durante una sesión, el modo automático se pausa y Claude Code vuelve a pedirle confirmación. Estos umbrales no se pueden configurar. En el modo no interactivo, con la opción -p, no hay nadie a quien pedir confirmación, por lo que los bloqueos repetidos cancelan la sesión.

Este segundo comportamiento es el que causa problemas en un servidor remoto. Una ejecución desatendida que alcanza el límite se detiene y espera a una persona que no está mirando el terminal. Limitar lo que el agente intenta hacer es la otra parte de la solución, y una skill que orienta al agente hacia el cambio mínimo que funciona evita que una sesión se desvíe hacia las acciones extensas que el clasificador bloquea.

Dónde se encuentran los modos en settings.json

Todo lo anterior es un objeto dentro de un archivo de configuración.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Las reglas se evalúan en orden: denegar, después preguntar y, por último, permitir. La primera coincidencia en ese orden determina el resultado. Una regla más específica no prevalece sobre otra más amplia si esta aparece antes. Una regla de denegación para Bash(aws *) bloquea aws s3 ls aunque también se haya permitido ese comando exacto. Por tanto, una regla de denegación no puede tener excepciones.

ask es el tipo de regla que resulta útil en el modo automático. El modo automático elimina la confirmación rutinaria, y una regla ask vuelve a solicitarla para el comando específico que el usuario debe revisar. El comando de despliegue debe estar ahí. También Bash(git push *) si quiere establecer un punto de control antes de que el código salga del servidor. Mantener los archivos de credenciales en deny es la otra parte de esta configuración, y se complementa con mantener las credenciales fuera del alcance de un agente desde el principio.

Los propios archivos de configuración, de menor a mayor precedencia:

• ~/.claude/settings.json: configuración del usuario, aplicada en todos los proyectos.
• .claude/settings.json: configuración del proyecto, confirmada en el repositorio.
• .claude/settings.local.json: configuración propia para un repositorio, excluida mediante git.
• Configuración administrada, desplegada por un administrador. En Linux, ese archivo es /etc/claude-code/managed-settings.json. Nada puede sobrescribir una regla de permisos administrada, incluida una opción de línea de comandos.

Aquí hay una trampa con una causa documentada. defaultMode: "auto" se ignora cuando procede de .claude/settings.json o .claude/settings.local.json, desde Claude Code v2.1.142, para impedir que un repositorio active el modo automático por sí mismo al incluir un archivo de configuración. Si lo establece ahí, la sesión se inicia en modo default sin mostrar ningún error. Mueva esa línea a ~/.claude/settings.json. Ejecute /permissions para mostrar todas las reglas activas junto al archivo del que proceden.

Los dos interruptores que desactivan un modo

Los administradores disponen de dos interruptores de emergencia. Ambos aceptan la cadena "disable" en lugar de un valor booleano.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

La documentación especifica con precisión dónde colocarlos:

Para impedir que se use el modo bypassPermissions o auto, establezca permissions.disableBypassPermissionsMode o permissions.disableAutoMode en "disable" en cualquier archivo de configuración. Resultan especialmente útiles en configuraciones administradas, donde no se pueden sobrescribir.

disableAutoMode elimina auto del ciclo de Shift+Tab y rechaza --permission-mode auto durante el arranque. disableBypassPermissionsMode hace lo mismo con el modo de omisión y funciona desde cualquier ámbito. Por tanto, puede establecerlo en su propio ~/.claude/settings.json para impedirse el acceso a un modo que preferiría no activar a las 2am en un servidor en producción. En un equipo que usan otras personas, coloque ambos en /etc/claude-code/managed-settings.json, porque un archivo de configuración del usuario pertenece a ese usuario y uno administrado no.

Por qué el modo automático en una VPS necesita un límite de aislamiento

El clasificador revisa una acción cada vez. No contiene lo que hace después una acción aprobada. La documentación establece claramente la diferencia:

El clasificador es un control por acción, no un límite de aislamiento. Por tanto, un límite de aislamiento sigue proporcionando defensa en profundidad para ejecuciones desatendidas y no es necesario del mismo modo que para --dangerously-skip-permissions.

Por tanto, la combinación adecuada para un sistema remoto es el modo automático y un entorno que esté dispuesto a perder, no bypassPermissions más esperanza. El modo de omisión está documentado sólo para entornos aislados: contenedores, máquinas virtuales o contenedores de desarrollo sin acceso a Internet, donde Claude Code no puede dañar el sistema host. Una VPS que ejecuta la base de datos y el reverse proxy no cumple ninguna de esas condiciones.

Tres medidas son las más importantes en un servidor. Ejecute Claude Code como un usuario normal, nunca como root. Proporcione a ese usuario un directorio de trabajo y ningún otro recurso que sea importante leer. Reconstruya el sistema en lugar de repararlo. Este es el motivo para usar una máquina virtual desechable que elimine después de cada trabajo. Los detalles de hardening relacionados con estas medidas, desde la creación del usuario hasta las reglas del firewall, se explican en la guía completa de seguridad para ejecutar Claude Code en una VPS, por lo que no se repiten aquí.

Claude Code aplica por sí mismo la regla sobre root. En Linux y macOS se niega a iniciar en modo de omisión con sudo o como root:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Esta comprobación se omite dentro de un sandbox reconocido. Por eso, la opción documentada para ejecutar agentes autónomos en contenedores es un contenedor de desarrollo que ejecute Claude Code como un usuario que no sea root. Si controla el agente desde un teléfono o un portátil mediante SSH, el mismo razonamiento se aplica a una sesión de Claude Code de larga duración mantenida abierta en tmux: nadie supervisa el indicador mientras la sesión está activa.

Configurar el sandbox de Bash en un VPS con Ubuntu

El sandbox integrado restringe el acceso al sistema de archivos y a la red de cada comando de Bash que ejecuta Claude, y el sistema operativo aplica esas restricciones también a los procesos secundarios. En Linux necesita dos paquetes.

sudo apt-get install bubblewrap socat

Inicie Claude Code y ejecute /sandbox. El panel se abre con una pestaña Mode y otra Overrides, además de una pestaña Dependencies que muestra todo lo que falta. La comprobación de dependencias se ejecuta al iniciar, por lo que debe reiniciar Claude Code después de instalar los paquetes. De lo contrario, el panel seguirá indicando que faltan.

En Ubuntu 24.04 y posteriores, la política predeterminada de AppArmor impide que bubblewrap cree los espacios de nombres de usuario que necesita, por lo que el sandbox no se inicia. Compruebe si esto se aplica a su servidor:

sysctl kernel.apparmor_restrict_unprivileged_userns

Un 0, o un error que indique que la clave no existe, significa que no hay nada que hacer. Un 1 significa que bwrap necesita su propio perfil:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

El perfil se aplica al propio bwrap, no a los comandos que ejecuta dentro del sandbox. Después, limite el ámbito en la configuración:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Ese bloque debe estar en el .claude/settings.json del proyecto, porque . se resuelve en la raíz del proyecto únicamente desde la configuración del proyecto. Si coloca las mismas líneas en ~/.claude/settings.json, . se resolverá en ~/.claude. De ese modo, la regla denyRead mantiene bloqueados los archivos del proyecto y todos los comandos no pueden leer el código que deben editar.

Tenga en cuenta lo que esto no cubre. El sandbox restringe Bash y sus procesos secundarios. Las herramientas de archivos integradas se ejecutan dentro del proceso de Claude Code, mientras que los servidores MCP (model context protocol) y los hooks son procesos independientes que se ejecutan sin restricciones en el host. Para colocar todos estos componentes detrás de un único límite, ejecute todo el proceso de Claude Code dentro de un contenedor, una máquina virtual o el paquete @anthropic-ai/sandbox-runtime, que en el momento de redactar este texto es una versión preliminar de investigación en fase beta.

¿Qué modo corresponde a cada configuración?

Un repositorio individual en tu propio portátil

Usa auto, con reglas ask para las acciones que quieras permitir automáticamente. Estás frente al teclado, el mecanismo alternativo del clasificador puede pedirte confirmación y el daño queda limitado a una máquina que controlas. Este es el caso para el que se diseñó el valor predeterminado del 14 August.

Un VPS compartido

Usa auto por usuario, definido en el propio ~/.claude/settings.json de cada usuario, en un servidor donde la cuenta que ejecuta Claude Code no sea root ni pueda leer el trabajo de los demás usuarios. Implementa disableBypassPermissionsMode como "disable" en /etc/claude-code/managed-settings.json, junto con las reglas de denegación que protegen las rutas compartidas. Un servidor compartido es el caso más claro en el que bypassPermissions es incorrecto, porque no existe el límite de aislamiento que presupone ese modo: los demás usuarios están dentro de él.

CI y sesiones desatendidas

Usa dontAsk con una lista explícita allow de los comandos que necesita el trabajo. La denegación automática es el comportamiento correcto ante errores cuando ninguna persona verá una solicitud de confirmación. El modo automático también se ejecuta sin interacción, pero los bloqueos repetidos del clasificador abortan una sesión -p, por lo que un trabajo que los encuentre falla a mitad de ejecución, con parte del trabajo ya realizada. Mantén bypassPermissions para un contenedor o una máquina virtual que reconstruyas desde una imagen, y no lo uses en ningún host que también ejecute algo importante.

FAQ

¿Cuándo se convierte el modo automático en el modo predeterminado en Claude Code?

A partir del 14 de agosto de 2026, para las sesiones nuevas de los planes Pro, Max y Team. La documentación añade que puede cambiar de modo en cualquier momento, que un valor predeterminado configurado por usted se mantiene hasta que acepte el aviso de cambio único y que un valor predeterminado administrado por su organización no cambia. El anuncio indica que el modo automático seguirá siendo opcional para los planes Enterprise y para las cuentas que usen la API durante la primera fase del despliegue. Compruebe el modo activo de una sesión en la barra de estado, que muestra ⏵⏵ auto mode on en el modo automático.

¿Debo usar el modo automático o bypassPermissions en un VPS?

Use el modo automático junto con un límite de aislamiento. El clasificador revisa cada acción antes de ejecutarla, pero la documentación indica explícitamente que es un control por acción y no un límite de aislamiento. Por tanto, una ejecución desatendida sigue necesitando un contenedor, una máquina virtual o un sistema que pueda reconstruir. bypassPermissions omite completamente las comprobaciones y está documentado únicamente para entornos aislados. Claude Code no inicia en ese modo como root en Linux y muestra --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

¿Cómo impido que cualquier usuario de mi servidor use el modo automático o el modo bypass?

Establezca permissions.disableAutoMode y permissions.disableBypassPermissionsMode en la cadena "disable" dentro de /etc/claude-code/managed-settings.json. La configuración administrada tiene prioridad sobre todos los demás ámbitos, por lo que ningún archivo de configuración del usuario ni ninguna opción de línea de comandos puede anularla. disableAutoMode elimina auto del ciclo de Shift+Tab y rechaza --permission-mode auto durante el arranque. disableBypassPermissionsMode también funciona desde cualquier ámbito, por lo que un usuario puede establecerlo en su propio ~/.claude/settings.json.

¿Por qué se ignora mi configuración defaultMode: "auto"?

Porque está en el archivo incorrecto. Desde Claude Code v2.1.142, defaultMode: "auto" se ignora cuando procede de .claude/settings.json o .claude/settings.local.json. Así se impide que un repositorio habilite por sí mismo el modo automático mediante un archivo de configuración. La sesión se inicia en el modo default y no muestra ningún error. Mueva la configuración a ~/.claude/settings.json y ejecute /permissions para confirmar de qué archivo procede cada regla activa. Si el modo automático sigue sin estar disponible, compruebe el requisito del modelo: los modelos antiguos, como Sonnet 4.5, no son compatibles con ningún proveedor.