Permisos de Claude Code: las reglas que deberías escribir ya

Llevas meses dándole a “sí, adelante” sin leer el diálogo. El 14 de agosto de 2026 ese diálogo deja de aparecer solo: las sesiones nuevas de Claude Code en Pro, Max y Team que no hayan fijado un modo a mano arrancarán en auto mode, donde un clasificador decide en tu lugar ^[1]. El clasificador es una capa real y funciona. Pero el sitio físico donde vivía tu criterio, ese prompt de confirmación que leías a medias, desaparece; y si tu criterio no está escrito en ningún fichero, a partir de esa fecha deja de existir.

La buena noticia es que Claude Code tiene un sistema de permisos de grano bastante fino, con reglas que se evalúan antes que el clasificador y que casi nadie usa. Aquí están las palancas, en qué fichero va cada una y cuál es una garantía dura frente a cuál es solo una sugerencia.

Qué cambia el 14 de agosto de 2026

Dos cosas, con fechas distintas. La primera ya está en vigor: desde el 7 de agosto de 2026, Anthropic dejó de cobrar el coste del clasificador a los usuarios de Pro, Max y Team ^[1]. Ese coste nunca fue el de tu modelo, y conviene entenderlo: el clasificador corre por defecto en Claude Sonnet 5, no en el que tengas seleccionado con /model ^[2]. Donde se sigue facturando, que es Enterprise, la Claude API y las nubes, cada comprobación gasta tokens de ese modelo aparte. La segunda es la del titular: a partir del 14 de agosto, las sesiones nuevas en esos mismos tres planes arrancan en auto mode.

Quedan fuera de momento Claude Enterprise, la Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud Agent Platform y Microsoft Foundry, donde auto mode sigue siendo opt-in ^[1]. Pero es un “de momento” con fecha aproximada: Anthropic dice que en el mes siguiente, trabajando con sus socios de nube, planea hacerlo default también ahí y dejar de cobrar el coste del clasificador ^[1]. Si lees esto en septiembre, da por hecho que la lista se ha movido y compruébalo. Si ya tenías un defaultMode puesto a mano, se queda como está salvo que aceptes el aviso puntual del cambio; si lo gestiona tu organización, no se mueve ^[2].

Y conviene fijar lo que dice la propia documentación: auto mode reduce los prompts de permiso, no garantiza seguridad ^[2]. Es una capa de revisión, no un guardarraíl. El guardarraíl lo escribes tú, en JSON.

Los seis modos, y cuál usas sin saberlo

El modo fija el suelo: qué se ejecuta sin preguntar cuando ninguna de tus reglas ha casado. Las reglas van primero, y el modo decide lo que queda ^[2].

Modo	Qué corre sin preguntar	Para qué
`default`	Solo lecturas	El modo con más supervisión. En la CLI, en `claude --help` y en las extensiones se llama Manual, y acepta el alias `manual` desde la v2.1.200
`acceptEdits`	Lecturas, edición de ficheros y comandos habituales de sistema de ficheros (`mkdir`, `touch`, `rm`, `rmdir`, `mv`, `cp`, `sed`) dentro del directorio de trabajo o de `additionalDirectories`	Iterar sobre código que revisas después con `git diff`
`plan`	Lecturas, más lo que apruebe el clasificador si auto mode está disponible y `useAutoModeDuringPlan` sigue activo, que lo está por defecto	Explorar antes de tocar nada
`auto`	Todo, con revisión del clasificador por detrás	Tareas largas
`dontAsk`	Solo tus reglas `allow`, los comandos de lectura integrados y lo que apruebe un hook `PreToolUse`	CI. Deniega en vez de preguntar
`bypassPermissions`	Todo, salvo tus reglas `deny` y `ask` explícitas y el cortacircuitos de `rm -rf /` y `rm -rf ~`	Contenedores y VMs aislados

dontAsk no aparece nunca en el ciclo de Shift+Tab: lo activas con --permission-mode dontAsk al arrancar, o dejándolo fijado con defaultMode: "dontAsk" en settings ^[2].

bypassPermissions es más traicionero de lo que parece. No entra en el ciclo salvo que lo hayas habilitado, pero basta con haberlo habilitado una vez: arrancar con --permission-mode bypassPermissions, con --dangerously-skip-permissions, con permissions.defaultMode: "bypassPermissions" o incluso con --allow-dangerously-skip-permissions, que añade el modo al ciclo sin activarlo, lo mete en la rotación de Shift+Tab para el resto de la sesión ^[2]. Los modos opcionales se colocan detrás de plan, con bypassPermissions el primero y auto el último, así que si tienes los dos habilitados pasas por encima de bypass cada vez que ciclas hacia auto. Es decir: en la configuración más habitual de quien lo activa, sí puedes acabar en él pulsando teclas.

El que de verdad importa es dónde se fija el default:

Diagrama de jerarquía mostrando el orden de precedencia de los ficheros de configuración de Claude Code: managed settings, flags de CLI, settings de usuario, settings de proyecto y settings local de proyecto, con una nota destacando que estos dos últimos no pueden auto-concederse auto mode. — Qué fichero gana cuando varios definen la misma clave de permisos: managed settings y los flags de CLI pesan más que cualquier fichero de proyecto, y desde la v2.1.142 un repositorio clonado no puede concederse auto mode a sí mismo en su propio settings.json.

{
  "permissions": {
    "defaultMode": "auto"
  }
}

Ese bloque tiene que vivir en ~/.claude/settings.json. Desde la v2.1.142, Claude Code ignora defaultMode: "auto" cuando viene de .claude/settings.json o .claude/settings.local.json, precisamente para que un repositorio que te clonas no pueda concederse a sí mismo el modo sin fricción ^[2]. Si pones auto ahí y la sesión arranca en Manual sin decirte nada, ya sabes por qué.

deny → ask → allow: el orden que rompe tus reglas

Las reglas se evalúan en tres pasadas, deny primero, luego ask, luego allow, y gana la primera que case. La especificidad de la regla no altera ese orden ^[3].

Eso rompe la intuición de cualquiera que venga de firewalls o de IAM: un deny amplio no admite excepciones. Si tienes Bash(aws *) en deny y Bash(aws s3 ls) en allow, el listado de S3 está bloqueado. La regla concreta no gana, porque nunca llega a evaluarse. Para dejar un hueco, la única vía es no denegar tan ancho.

Y hay dos formas de denegar que hacen cosas distintas. Un nombre pelado como "Bash" elimina la herramienta del contexto del modelo: Claude ni la ve. Un patrón como "Bash(rm *)" la deja disponible y bloquea la llamada cuando Claude intenta hacerla ^[3]. La segunda es la que quieres casi siempre, porque un agente sin Bash es poco más que un lector de ficheros.

Sintaxis de reglas que casi nadie usa

El patrón Herramienta(cosa) da bastante más de sí que Bash(npm test).

Matching por parámetro. Las reglas deny y ask casan contra un parámetro concreto de la llamada: Agent(model:opus) casa las invocaciones de subagente que piden el nivel Opus, y Bash(run_in_background:true) los comandos lanzados en segundo plano ^[3]. Cada regla nombra un parámetro, así que para cerrar dos escribes dos reglas. Lo que no puedes es casar contra el campo principal de contenido: Bash(command:rm *) se ignora con un aviso de arranque, porque un comando compuesto lo esquivaría trivialmente.

Globs en la posición del nombre de herramienta. En deny y ask, "mcp__*" casa todas las herramientas MCP de todos los servidores de golpe ^[3]. En allow no vale: ahí el glob solo se acepta tras un prefijo literal mcp__<servidor>__, para que la regla nombre un servidor que tú configuraste.

Wildcard en medio. Bash(git * main) casa git checkout main, git merge main y git push origin main, porque un solo * abarca varios argumentos incluidos los espacios ^[3].

El espacio antes del asterisco. Bash(ls *) exige frontera de palabra: casa ls -la pero no lsof. Bash(ls*), sin el espacio, casa las dos ^[3]. Ese carácter invisible separa una regla que hace lo que crees de otra que abre un agujero.

Cd(...) y Agent(...). Un deny sobre Cd a secas desactiva /cd entero; con patrón, acota adónde puede relocalizarse la sesión. Agent(Explore) apaga ese subagente. Y WebFetch(domain:*.example.com) casa cualquier subdominio a cualquier profundidad, pero no example.com a pelo ^[3].

Tres trampas que hacen que tu regla no proteja nada

Los wrappers que no se quitan. Antes de comparar una regla de Bash, Claude Code retira un conjunto fijo de envoltorios: timeout, time, nice, nohup, stdbuf, los builtins command y builtin, el noglob de zsh, y xargs cuando va sin flags. Por eso Bash(npm test *) cubre también timeout 30 npm test ^[3]. La lista no es configurable y no incluye los runners de entorno: npx, docker exec, devbox run, mise exec, direnv exec. Como esos ejecutan lo que les pases, una regla Bash(devbox run *) autoriza de hecho devbox run rm -rf .; lo correcto es una regla por comando interno, Bash(devbox run npm test). Y watch, setsid, ionice, flock y find con -exec o -delete nunca se auto-aprueban por una regla de prefijo.

El anclaje de rutas. Read y Edit usan semántica gitignore: //ruta es absoluta desde la raíz del sistema de ficheros, mientras que /ruta se ancla al origen del fichero de settings que la define ^[3]. Un Read(/secrets/**) escrito en ~/.claude/settings.json protege ~/.claude/secrets/**, no el directorio secrets de tu proyecto. Es la trampa más cara porque no falla ruidosamente: la regla existe, se carga, y no cubre nada de lo que creías. Hay un tercer anclaje que resuelve el caso, ~/ruta, que parte de tu directorio home vaya donde vaya el fichero de settings: Read(~/.ssh/**) es lo que quieres escribir, y Read(~/.zshrc) lee el de tu home ^[3]. Para una regla de usuario que deba aplicarse dentro de cualquier proyecto, usa // o ~/, nunca / a secas.

La herramienta equivocada. Claude Code comprueba los permisos de fichero contra reglas Edit(ruta) y Read(ruta), y solo contra esas. Si la escribes sobre Write(...), NotebookEdit(...), Glob(...) o el antiguo MultiEdit(...), la acepta, avisa al arrancar y no la consulta jamás ^[3]. Edit(docs/**) cubre toda la escritura, Read(docs/**) toda la lectura. El aviso solo salta con reglas que llevan ruta: un Write a secas en deny no avisa de nada y sí se aplica, pero a nivel de herramienta entera ^[3].

Un cuarto detalle: qué pasa con los symlinks

Cuando Claude toca un enlace simbólico, las reglas se comprueban contra dos rutas, el enlace y su destino, y allow y deny se comportan distinto. Una regla allow exige que casen las dos; si el enlace vive en un directorio permitido pero apunta fuera, te pregunta igual. Una regla deny bloquea si casa cualquiera de las dos ^[3].

Cómo se le ponen límites a un clasificador

Dentro de auto mode hay dos maneras de decir “esto no, o al menos pregúntame antes”, y solo una aguanta.

Diagrama de flujo mostrando el orden de evaluación de una llamada a herramienta en Claude Code: ruta protegida, hook PreToolUse, reglas deny, reglas ask con patrón, y después el modo activo — con el detalle interno del clasificador de auto mode (hard_deny, soft_deny, allow, intención explícita) — hasta llegar a ejecutada o bloqueada, con el sandbox del sistema operativo como capa independiente. — El orden real en que se decide si una llamada se ejecuta: primero las capas deterministas (ruta protegida, hook, deny, ask con patrón), y solo si nada de eso actúa entra en juego el modo activo. Dentro de auto mode, el clasificador resuelve hard_deny, luego soft_deny, luego allow y por último la intención explícita del usuario.

La primera es decirlo en el chat. El clasificador lee la conversación, así que “no hagas push hasta que yo revise” bloquea de verdad las acciones que casen, y el límite sigue en pie hasta que tú lo levantes. Pero no se guarda como regla: el clasificador lo relee del transcript en cada comprobación, y si la compactación de contexto se lleva el mensaje que lo enunció, el límite se evapora ^[2].

La segunda es una regla ask con patrón, que se evalúa antes que el clasificador y siempre fuerza el prompt, incluso en auto mode ^[4]:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ],
    "deny": [
      "Bash(terraform destroy *)",
      "Read(//**/.ssh/**)"
    ]
  }
}

Ese bloque es el patrón que quieres si vas a vivir en auto mode: el agente trabaja sin interrupciones y tú recuperas el control en los dos puntos donde el trabajo sale de tu máquina.

Por debajo, el clasificador tiene su propia configuración en el bloque autoMode, con cuatro listas. environment describe qué infraestructura es tuya y por tanto de confianza; el detalle de cómo se rellenan sus slots está en la guía de cómo describirle tu infraestructura al clasificador. Las otras tres, hard_deny, soft_deny y allow, redefinen el criterio, y se escriben en prosa: el clasificador las lee como reglas en lenguaje natural ^[4].

Su precedencia interna va en cuatro escalones. hard_deny bloquea sin excepción. soft_deny bloquea después. allow actúa como excepción sobre los soft_deny. Y la intención explícita del usuario levanta los soft_deny que queden, con un matiz que vale la pena memorizar: una petición general no cuenta. Pedir “limpia el repo” no autoriza un force push; pedir “haz force push de esta rama” sí ^[4].

Aquí está la trampa que se lleva a más gente por delante. Estas listas no se fusionan con las de fábrica: si escribes un array sin el token literal "$defaults", reemplazas la lista entera de esa sección.

{
  "autoMode": {
    "soft_deny": [
      "$defaults",
      "Nunca modifiques ficheros bajo infra/terraform/prod/: los cambios de infraestructura de producción pasan por el flujo de revisión"
    ]
  }
}

Ese "$defaults" empalma las reglas integradas en esa posición, así que las tuyas pueden ir antes o después y sigues heredando las actualizaciones que Anthropic publique ^[4]. Sin él:

{
  "autoMode": {
    "soft_deny": ["Nunca modifiques ficheros bajo infra/terraform/prod/"]
  }
}

Eso acaba de borrar todos los bloqueos de fábrica de esa lista, incluidos el de force push, el de curl | bash, el de los deploys a producción y el que impide que Claude desactive su propia supervisión ^[4]. El fichero pasó de endurecer la configuración a aflojarla, sin ningún error en pantalla. claude auto-mode config imprime lo que el clasificador usa de verdad, con "$defaults" ya expandido, y claude auto-mode critique revisa tus reglas propias y señala las ambiguas.

Queda una palanca más. Por defecto, una regla allow estrecha como Bash(npm test) sobrevive en auto mode y se resuelve antes de que el clasificador vea nada, así que un argumento destructivo que tu prefijo no anticipó puede colarse. autoMode.classifyAllShell: true suspende todas las reglas allow de Bash y también las de PowerShell mientras auto mode está activo ^[4]. Cuesta latencia y una llamada más por comando; en una máquina con permisos amplios, sale a cuenta.

Mecanismo	Qué hace	Cuándo se evalúa	¿Puede saltárselo la intención del usuario?
Límite dicho en la conversación	El clasificador bloquea lo que case	Dentro del clasificador, releyendo el transcript	Se pierde si la compactación borra el mensaje
`permissions.ask` con patrón	Fuerza prompt en todos los modos, salvo en `dontAsk`, donde deniega en vez de preguntar	Antes del clasificador	No. El clasificador no puede auto-aprobarlo
`permissions.deny`	Bloquea sin más	Antes del clasificador	No
`autoMode.soft_deny`	Bloquea acciones destructivas	Dentro del clasificador, segundo escalón	Sí: con una petición explícita y concreta, y también con un `allow` que el desarrollador se ponga en su settings personal
`autoMode.hard_deny`	Bloquea de forma incondicional	Dentro del clasificador, primer escalón	No
Hook `PreToolUse` con salida 2	Corta la llamada a la herramienta	Antes de que se evalúen las reglas allow	No
Sandbox del sistema operativo	Restringe ficheros y red del proceso	En el kernel, fuera de Claude Code	No

Las capas que las reglas de permisos no cubren

Hay un conjunto de rutas que nunca se auto-aprueban, pase lo que pase en tus reglas allow: .git, .config/git, .claude (con la excepción de .claude/worktrees, donde Claude guarda sus propios worktrees), .vscode, .idea, .husky, .devcontainer, .cargo, .yarn, .mvn, y ficheros sueltos como .gitconfig, .zshrc, .npmrc o .mcp.json ^[2]. Tus reglas allow no las pre-aprueban: la comprobación corre antes de que se evalúen, así que un Edit(.claude/**) en tus settings no cambia nada. En auto mode esas escrituras van al clasificador, en dontAsk se deniegan y en bypassPermissions pasan.

Los hooks PreToolUse son la capa determinista. Corren antes del prompt de permiso, y uno que sale con código 2 corta la llamada antes de que se evalúen las reglas allow ^[3]. Eso permite un patrón que las reglas solas no dan: "Bash" en allow para que todo corra sin fricción, más un hook que rechace la lista corta de comandos que te importan. Aflojar no puede: si una regla deny casa, la llamada se bloquea aunque el hook devuelva "allow".

Con un aviso importante, y es el que más va a doler a partir del 14 de agosto: ese patrón no sobrevive dentro de auto mode. Al entrar, Claude Code suspende las reglas allow amplias que conceden ejecución arbitraria de código, y ahí caen Bash(*) y su equivalente "Bash" a secas, PowerShell(*), los intérpretes con comodín tipo Bash(python*), los comandos run de gestores de paquetes y las reglas allow sobre Agent ^[2]. Las estrechas, Bash(npm test), sí pasan, y las suspendidas vuelven en cuanto sales del modo. No verás ningún error: escribes la regla, el hook queda de adorno y sigues con la fricción sin entender por qué. Así que el patrón vale fuera de auto mode, o dentro con reglas estrechas.

Y luego está el sandbox, la única capa que frena a un script. Las reglas deny de Read y Edit se aplican a las herramientas de fichero de Claude y a los comandos de fichero que Claude Code reconoce dentro de Bash, como cat, head o sed. No se aplican a un subproceso que abre ficheros por su cuenta, es decir, a cualquier script de Python o de Node que Claude escriba y ejecute ^[3]. Para que un Read(**/.env) denegado signifique algo frente a un open('.env') dentro de ese script, necesitas el sandbox del sistema operativo, que sí combina tus reglas de fichero con su propia frontera.

Si esto va a un equipo, los managed settings ganan sobre todo lo demás, incluidos los flags de CLI. permissions.disableAutoMode: "disable" quita auto mode del ciclo y rechaza --permission-mode auto al arrancar, y permissions.disableBypassPermissionsMode hace lo propio con el modo sin comprobaciones. Hay además claves que solo se leen desde ahí, como allowManagedPermissionRulesOnly (los settings de usuario y de proyecto dejan de poder definir reglas), allowManagedHooksOnly o strictPluginOnlyCustomization ^[3].

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Bash(kubectl * --context prod*)"]
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true
}

Y una cosa que conviene tener clara antes de repartir política corporativa por autoMode: las entradas de cada ámbito se combinan, un desarrollador no puede quitar las que vengan de managed settings, pero como los allow funcionan dentro del clasificador como excepciones a los bloqueos blandos, un allow que se ponga en su settings personal sí puede levantar un soft_deny de la organización. La suma es aditiva, no una frontera de política ^[4]. Para lo que no debe ejecutarse jamás, la recomendación de la propia documentación es permissions.deny en managed settings, que se evalúa antes del clasificador y nadie puede sobrescribir ^[4].

Un detalle que sorprende a quien reparte configuración por repositorio: las reglas allow de un .claude/settings.json no se aplican hasta que aceptas el diálogo de confianza de ese workspace, porque conceden capacidad. Las deny y las ask se aplican desde el principio, porque solo restringen ^[3].

Cuándo auto mode se rinde

El clasificador también lleva la cuenta de sus propios bloqueos. Si tumba tres acciones seguidas, o veinte en total dentro de la misma sesión, auto mode se pausa y Claude Code vuelve a preguntarte como en Manual ^[2]. Apruebas el prompt que salga y auto mode se reanuda. Los dos umbrales están fijados y no se configuran: cualquier acción permitida pone a cero el contador de seguidas, mientras que el de veinte se arrastra durante la sesión y solo se reinicia cuando llega a su propio límite y dispara la pausa ^[2].

Eso en interactivo. En modo no interactivo con -p no hay nadie a quien preguntar, así que los bloqueos repetidos abortan la sesión ^[2]. Si vas a meter Claude Code en CI dentro de auto mode, ese es el fallo que verás: no un aviso, un job caído a mitad.

Cada denegación queda registrada. /permissions tiene una pestaña “Recently denied” con la llamada bloqueada tal cual, y pulsando r sobre una la marcas para reintentar: al salir del diálogo, Claude Code le dice al modelo que puede volver a intentarla y sigue la conversación ^[4]. Cuando la misma denegación se repite, casi siempre es que al clasificador le falta contexto de tu infraestructura, y eso se arregla en autoMode.environment, no insistiendo.

Y si prefieres reaccionar a los bloqueos por código en vez de a mano, hay un hook PermissionDenied ^[4].

Errores comunes

Poner autoMode o defaultMode: "auto" en el settings del repo. El clasificador no lee autoMode de .claude/settings.json, y desde la v2.1.207 tampoco de .claude/settings.local.json, que antes sí leía ^[4]. Los tres ámbitos que sí lee son ~/.claude/settings.json, los managed settings y el JSON que le pases con --settings. Si el bloque es tuyo, muévelo a ~/.claude/settings.json; si es de la organización, a managed settings, que es donde toca.

Definir soft_deny sin "$defaults". El error más caro de la lista, porque el fichero parece más estricto y es más laxo.

Esperar que un allow específico gane a un deny amplio. No gana. Nunca se evalúa.

Escribir la regla sobre Write(...) o Glob(...). Se acepta, avisa al arrancar y no se consulta. Si tu política de ficheros no está en Edit(...) y Read(...), no está.

Confiar en la frase del chat. “No toques producción hasta que yo lo revise” funciona mientras ese mensaje siga en la ventana de contexto. En una sesión larga, con compactación de por medio, no es una garantía; es una preferencia que caduca sin avisar.

Checklist de configuración

permissions.defaultMode está en ~/.claude/settings.json, no en el settings del repo
Existen reglas ask con patrón para las acciones que sacan trabajo de tu máquina (Bash(git push *), Bash(gh pr create *))
Las reglas de fichero están escritas sobre Edit(...) y Read(...), y las rutas de usuario usan // o ~/ en vez de /
Toda lista de autoMode que hayas personalizado contiene "$defaults", verificado con claude auto-mode config
No hay reglas allow de runners de entorno del tipo Bash(npx *) o Bash(docker exec *)
Lo que nunca debe ejecutarse está en permissions.deny, no descrito en autoMode.soft_deny ni dicho en el chat
Si hay datos que ningún proceso debe leer, el sandbox está activado además de las reglas de Read

Con esas siete líneas escritas, el 14 de agosto no te cambia nada que no hayas decidido tú. Y si estás montando el entorno entero y no solo los permisos, el resto de la puesta a punto la tienes en la guía práctica de proyectos de Claude.

Fuentes

Auto mode becomes the default in Claude Code — Anthropic — la fecha del 14 de agosto de 2026, el alcance por planes, el fin del cobro del clasificador efectivo el 7 de agosto y el estado opt-in de Enterprise, la API y las nubes.
Choose a permission mode — Claude Code Docs — la tabla de los seis modos, el ignorado de defaultMode: "auto" desde la v2.1.142, la advertencia de que auto mode no garantiza seguridad, los límites dichos en conversación y la lista de protected paths.
Configure permissions — Claude Code Docs — la precedencia deny → ask → allow, la sintaxis de reglas, el stripping de wrappers, el anclaje de rutas de Read y Edit, las reglas sobre Write/Glob, los hooks PreToolUse y los managed settings.
Configure auto mode — Claude Code Docs — las listas de autoMode, el token "$defaults", la precedencia interna del clasificador, classifyAllShell y los subcomandos claude auto-mode.

Preguntas Frecuentes

¿Tengo que hacer algo antes del 14 de agosto de 2026?

Si ya tienes un permissions.defaultMode puesto a mano, se respeta y no cambia salvo que aceptes el aviso puntual. Si nunca lo has tocado y estás en Pro, Max o Team, las sesiones nuevas arrancarán en auto mode a partir de esa fecha, así que merece la pena dedicar diez minutos a escribir las reglas ask y deny que hoy sustituyes por leer los diálogos.

¿Por qué no me aparece auto mode?

Casi siempre es el modelo. En la Claude API y en Claude Platform on AWS hace falta Opus 4.6 o posterior, Sonnet 4.6 o posterior, o Fable 5. En Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry y las sesiones con sesión iniciada del Claude apps gateway el listón sube: solo valen Sonnet 5, Opus 4.7 o posterior y Fable 5. Sonnet 4.5, Opus 4.5, cualquier Haiku y los modelos claude-3 se quedan fuera en todos los proveedores ^[2]. Si el modelo cumple, mira si tu organización lo ha apagado con permissions.disableAutoMode en managed settings. Y si no aparece, no es una caída pasajera: es un requisito sin cumplir ^[2].

¿Cómo dejo Claude Code como estaba, preguntando por todo?

Poniendo "permissions": {"defaultMode": "default"} en ~/.claude/settings.json. Ese es el modo que la CLI muestra como Manual, y desde la versión 2.1.200 también acepta el alias manual. Puedes volver a él en cualquier momento durante una sesión con Shift+Tab.

¿Cómo fuerzo que me pregunte antes de un git push sin salir de auto mode?

Con una regla ask que lleve patrón, no el nombre pelado de la herramienta:

{ "permissions": { "ask": ["Bash(git push *)"] } }

Las reglas ask con patrón se evalúan antes que el clasificador y siempre fuerzan el prompt, así que el clasificador no puede auto-aprobar un push aunque el resto de la sesión siga sin interrupciones.

¿Puedo desactivar auto mode para todo mi equipo?

Sí, con permissions.disableAutoMode en "disable" dentro de managed settings. Eso quita auto del ciclo de Shift+Tab y rechaza --permission-mode auto al arrancar. Los managed settings ganan sobre los settings de usuario, los de proyecto y los flags de línea de comandos, así que un desarrollador no puede revertirlo desde su máquina.

¿Auto mode me protege de un prompt injection?

Ayuda, pero no es una protección completa y la documentación lo dice sin rodeos: reduce prompts de permiso, no garantiza seguridad. El clasificador ve tus mensajes, las llamadas a herramientas y tu CLAUDE.md, pero los resultados de las herramientas se le quitan, de modo que el contenido hostil de un fichero o de una web no lo manipula directamente. Contra un prompt injection que consiga que Claude intente algo destructivo, la garantía dura es una regla deny en managed settings o el sandbox del sistema operativo.