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 pedir confirmación y envía cada acción a un modelo clasificador independiente para que la revise primero. A partir del 14 de agosto de 2026, será el modo con el que se iniciarán las sesiones nuevas en los planes Pro, Max y Team. Puede cambiar de modo en cualquier momento, y no se sobrescribe un valor predeterminado que ya haya configurado.

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. Un valor predeterminado que haya configurado usted se mantiene, salvo que acepte el aviso de cambio único, y un valor predeterminado administrado por 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 permanece después del cambio. También permanece un 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 parte 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 no estará allí, por lo que el modo con el que se inicia una sesión será el modo que mantendrá durante horas.

Los 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. Claude Code aplica los seis modos directamente, no el modelo, porque decidir qué puede hacer una llamada a una herramienta es responsabilidad del arnés que rodea al modelo.

• default: Claude pregunta antes de usar cada herramienta nueva. Las lecturas dentro del directorio de trabajo se ejecutan sin preguntar. 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 preguntar, 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 antes 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 y las comprobaciones de seguridad, incluidas las escrituras en rutas protegidas como .git y .claude.

Pulse Shift+Tab durante una sesión para pasar de default a acceptEdits y a 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 la cuenta cumple los requisitos correspondientes. bypassPermissions sólo se incorpora cuando la sesión se inicia con --permission-mode bypassPermissions o --dangerously-skip-permissions. dontAsk nunca aparece en ese ciclo, por lo que debe configurarse con claude --permission-mode dontAsk.

El modo automático también necesita un modelo reciente, que suele ser la causa de que no aparezca. En agosto de 2026, la documentación indica Claude Opus 4.6 o posterior, Sonnet 4.6 o posterior y Fable 5 en la API de Anthropic, y señala que los modelos anteriores, como Sonnet 4.5, no son compatibles con ningún proveedor. Si Claude Code indica que el modo automático no está disponible, no se cumple alguno 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 conservan 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 ha solicitado. 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 exceda su solicitud, apunte a infraestructura no reconocida o parezca provocado por contenido hostil que Claude haya leído.

Bloqueado de forma predeterminada, en 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
• Force push
• Modificar infraestructura compartida
• Abrir un túnel o una reverse shell que haga accesible un servicio local desde Internet pública
• Imprimir una credencial o un token activo en la transcripción o en un archivo

Permitido 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 solo 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 confiar en este mecanismo, tenga en cuenta dos límites documentados. Primero, el clasificador ve sus mensajes, las llamadas a herramientas y el contenido de CLAUDE.md; los resultados de las herramientas se eliminan, por lo que 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 en 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.

Ese segundo comportamiento es el que causa problemas en un equipo remoto. Una ejecución desatendida que alcanza el límite se detiene y espera a una persona que no está mirando el terminal. Una segunda sesión de Claude Code en el mismo equipo no sustituye a esa persona, porque el texto enviado de una sesión a otra queda retenido hasta que la sesión receptora lo recoge, y una sesión pausada en una solicitud de permisos todavía necesita una respuesta humana. La otra mitad de la solución consiste en limitar lo que el agente intenta hacer, 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 detiene el clasificador. Mientras una skill dirige una tarea, un estilo de salida edita el prompt del sistema, por lo que un estilo que solicita cambios pequeños y precisos se aplica en todos los turnos de la sesión, en lugar de limitarse al único trabajo para el que se invocó.

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, preguntar y permitir. La primera coincidencia de esa secuencia determina el resultado. Una regla más específica no tiene prioridad sobre una regla más general que aparezca 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 solicitud rutinaria de confirmación. Una regla ask vuelve a solicitarla para el comando específico que quieras que revise una persona. El comando de despliegue debe estar ahí. También Bash(git push *) si quieres un punto de control antes de que el código salga del servidor. Mantener los archivos de credenciales en deny completa esta configuración y se combina 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 de tu usuario, aplicada en todos los proyectos.
• .claude/settings.json: configuración del proyecto, confirmada en el repositorio.
• .claude/settings.local.json: tu propia configuración para un repositorio, excluida mediante .gitignore.
• 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 la 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 por sí mismo el modo automático al distribuir un archivo de configuración. Si se establece allí, la sesión se inicia en el modo default sin mostrar ningún error. Mueve esa línea a ~/.claude/settings.json. Ejecuta /permissions para mostrar cada regla activa junto al archivo del que procede.

Los dos interruptores que desactivan un modo

Los administradores tienen dos interruptores de emergencia, y ambos requieren la cadena "disable" en lugar de un valor booleano.

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

La documentación indica 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. Son 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 lo que puede establecerlo en su propio ~/.claude/settings.json para impedirse el acceso a un modo que preferiría no usar a las 2am en un servidor en producción. En un equipo que utilizan otras personas, coloque ambos en /etc/claude-code/managed-settings.json, porque un archivo de configuración del usuario pertenece al usuario, mientras que uno administrado no.

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

El clasificador revisa una acción cada vez. No contiene las consecuencias de una acción aprobada. La documentación establece claramente el límite:

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

Por tanto, la combinación adecuada para un equipo remoto es el modo automático más 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 pueda dañar el sistema host. Un VPS que ejecuta la base de datos y el reverse proxy no pertenece a ninguna de esas categorías.

Tres medidas son las más importantes en un servidor. Ejecute Claude Code como un usuario normal, nunca como root. Asigne a ese usuario un directorio de trabajo y ningún otro contenido que merezca la pena leer. Vuelva a crear el equipo en lugar de repararlo; ese es el motivo para usar una máquina virtual desechable que se elimina después de cada trabajo. Los detalles de hardening que sustentan estas medidas, desde la creación del usuario hasta las reglas del firewall, se explican en la guía completa para ejecutar Claude Code de forma segura en un 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 iniciarse 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 respuesta documentada para trabajar de forma autónoma con 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 está supervisando el prompt mientras la sesión está activa. Nada de esto comienza hasta que el inicio de sesión funciona. Por tanto, si el equipo rechaza la conexión con Permission denied (publickey), la salida detallada de SSH indicará cuál de los cinco fallos tiene realmente.

Configurar el sandbox de Bash en un VPS de 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 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á indicándolos como ausentes.

En Ubuntu 24.04 y versiones 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 afecta a su sistema:

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, restrinja el límite 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 sólo desde la configuración del proyecto. Si coloca las mismas líneas en ~/.claude/settings.json, . se resuelve en ~/.claude en su lugar. 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 esos 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 documento es una versión preliminar de investigación en fase beta.

¿Qué modo corresponde a cada configuración?

Un repositorio independiente en su propio portátil

Use auto, con reglas ask para las acciones que quiera supervisar antes de permitirlas. Usted está delante del teclado, el mecanismo alternativo del clasificador puede solicitar su intervención y el impacto queda limitado a un equipo que controla. Este es el caso para el que se escribió el valor predeterminado del 14 August.

Un VPS compartido

Use auto por usuario, configurado en el propio ~/.claude/settings.json de cada usuario, en un equipo donde la cuenta que ejecuta Claude Code no sea root ni pueda leer el trabajo de los demás usuarios. Configure disableBypassPermissionsMode como "disable" en /etc/claude-code/managed-settings.json, junto con las reglas de denegación que protegen las rutas compartidas. Un equipo 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

Use dontAsk con una lista explícita allow de los comandos que necesita el trabajo. La denegación automática es el comportamiento correcto cuando nadie va a ver un aviso. El modo automático también se ejecuta de forma no interactiva, pero los bloqueos repetidos del clasificador cancelan una sesión -p, por lo que un trabajo que los encuentre falla a mitad de ejecución y deja el trabajo incompleto. Reserve bypassPermissions para un contenedor o una máquina virtual que reconstruya a partir de una imagen, y no lo use en ningún host que también ejecute algo importante.

FAQ

¿Cuándo se convierte el modo automático en el modo predeterminado de 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 salvo 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 sigue siendo opcional para los planes Enterprise y para las cuentas que usan la API durante la primera parte del despliegue. Compruebe el modo real de la 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 expresamente que es un control por acción, no un límite de aislamiento. Por tanto, una ejecución desatendida sigue necesitando un contenedor, una máquina virtual o un sistema que esté dispuesto a reconstruir. bypassPermissions omite todas las comprobaciones y está documentado únicamente para entornos aislados. Claude Code no se 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 alguien use el modo automático o el modo bypass en mi servidor?

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 la línea de comandos puede sobrescribirla. disableAutoMode elimina auto del ciclo 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, para impedir que un repositorio se conceda el modo automático mediante un archivo de configuración incluido en él. 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.