Auto Mode de Claude Code: configura autoMode.environment

Configura autoMode.environment para que el clasificador conozca tu infraestructura y deje de interrumpirte con falsos positivos.

Colaboradores: Ivan Garcia Villar, Manu Rubio

Si has activado el Auto Mode de Claude Code pensando que ibas a dejar de aprobar acciones manualmente, y en cambio sigues dándole al botón cada dos minutos, no es que hayas hecho algo mal. El problema es que el clasificador que hay detrás del Auto Mode no sabe nada de tu proyecto. No conoce tu empresa, tu API interna, ni tu bucket de S3. Para él, todo lo que no sea tu directorio de trabajo es sospechoso.

La primera vez que lo activé fue en un proyecto con un monorepo interno, tres servicios en *.acme.internal y un par de buckets de S3 propios. El clasificador bloqueó el primer push a la org de GitHub, luego un curl a la API interna, y a los cinco minutos el Auto Mode se pausó solo por demasiados bloqueos consecutivos. No estaba roto: simplemente no sabía nada de esa infraestructura.

Aquí explico qué es ese clasificador, por qué bloquea cosas que no debería, y cómo configurar autoMode.environment para que deje de interrumpirte.

Antes de continuar, necesitas saber:

  • Qué es Claude Code (la CLI de Anthropic para programar con Claude)
  • Qué es un archivo JSON y cómo editarlo

Nada más. No necesitas saber qué es un token, un context window, ni nada avanzado.

Qué ocurre cuando Claude quiere hacer algo

Cuando usas Claude Code, el modelo no solo responde texto. Puede ejecutar acciones reales: editar un archivo, correr un comando en la terminal, o hacer una petición a una URL. Cada vez que Claude decide hacer una de esas cosas, genera lo que se llama un tool call (una llamada a herramienta): básicamente le dice al sistema “quiero ejecutar este comando” o “quiero escribir en este archivo”.

Sin configuración especial, Claude Code te pregunta antes de cada tool call: “¿Puedo hacer esto?” Eso es el modo por defecto. Útil al principio, agotador cuando llevas una hora trabajando.

El Auto Mode existe para solucionar eso. En lugar de preguntarte a ti, Claude Code pasa cada tool call por un clasificador automático que decide si la acción es segura.

El clasificador: tres decisiones

Imagina un guardia de seguridad en la entrada de tu oficina. Cuando alguien llega, el guardia lo mira y decide: “pasa”, “no puedes entrar” o “espera aquí mientras llamo al responsable”. Eso es exactamente lo que hace el clasificador del Auto Mode.

Diagrama de flujo que muestra cómo el clasificador del Auto Mode evalúa cada tool call y toma una de tres decisiones: proceder, bloquear o pedir confirmación manual. Si se producen 3 bloqueos consecutivos o 20 en total, el Auto Mode se desactiva.
Cada tool call pasa por el clasificador antes de ejecutarse. Los contadores de bloqueo determinan cuándo el Auto Mode se pausa automáticamente.

Cada tool call que Claude genera pasa por este clasificador antes de ejecutarse. El clasificador toma una de tres decisiones:

Proceder: la acción parece segura, se ejecuta sin interrumpirte.

Bloquear: la acción parece peligrosa, se deniega. Claude recibe el motivo del bloqueo e intenta buscar una alternativa.

Confirmar: el clasificador no está seguro, te pasa la pelota para que lo apruebes tú manualmente.

Si el clasificador bloquea una acción 3 veces seguidas, o 20 veces en total durante la sesión, el Auto Mode se desactiva solo y Claude Code vuelve a preguntarte por todo. Cuando eso pasa, casi siempre es porque el clasificador no tiene suficiente contexto sobre tu entorno.

El clasificador no es una lista de reglas fija. Es otro modelo de lenguaje (Claude Sonnet 4.6) que corre en paralelo, lee el transcript de tu conversación más la acción pendiente, y decide. Eso tiene implicaciones: necesita contexto para funcionar bien.

Por qué el clasificador bloquea tu propia infraestructura

Aquí está el problema central: el clasificador no sabe nada de ti.

Por defecto, el clasificador solo confía en tu directorio de trabajo actual y en los remotes configurados en tu repositorio git. Todo lo demás es territorio desconocido. Una petición a api.miempresa.internal es tan sospechosa para él como una petición a cualquier servidor externo que no conoce.

¿El resultado? Bloqueos constantes en operaciones rutinarias:

  • Hacer push a tu organización de GitHub interna
  • Escribir en un bucket de S3 de tu empresa
  • Llamar a servicios internos como Jenkins o Artifactory
  • Usar registros de paquetes privados

El clasificador no es malo ni está roto. Simplemente está siendo conservador con información incompleta. Está haciendo su trabajo. Lo que falta es darle el contexto que necesita.

autoMode.environment: el mapa de tu infraestructura

El bloque autoMode.environment en tu settings es donde describes tu infraestructura de confianza. No en términos técnicos ni con patrones regex, sino en lenguaje natural, como si le explicaras a un compañero nuevo dónde están los servicios de tu empresa.

Antes de ver el código, hay algo importante: este bloque no va en el .claude/settings.json del repositorio. Va en tu settings personal (~/.claude/settings.json) o en el settings local del proyecto (.claude/settings.local.json). La diferencia: settings.json del repositorio es visible para todo el equipo en git; settings.local.json está en .gitignore y es exclusivo de tu máquina. El motivo es de seguridad: si el clasificador leyera reglas de un repositorio compartido, cualquier repo podría inyectar sus propias reglas de confianza. Ese archivo nunca debe llegar a git.

La estructura básica es esta:

// ~/.claude/settings.json — tu configuración personal
{
  "autoMode": {
    "environment": [
      "Organización: Acme Corp. Uso principal: desarrollo de software",
      "Control de versiones: github.com/acme-corp y todos sus repositorios",
      "Dominios internos de confianza: *.acme.internal, api.acme.com",
      "Servicios clave: CI en ci.acme.com, artefactos en artifacts.acme.com",
      "Buckets cloud de confianza: s3://acme-builds, s3://acme-deployments"
    ]
  }
}

Cada entrada es una frase. El clasificador las lee como instrucciones en lenguaje natural, no como patrones técnicos. Escribe lo mismo que le dirías a un compañero que empieza esta semana: qué es la empresa, dónde está el código, qué servicios internos usa el equipo.

La documentación oficial de Anthropic [1] proporciona una plantilla de partida que cubre los casos más comunes:

// Plantilla base recomendada — rellena los campos entre llaves
{
  "autoMode": {
    "environment": [
      "Organización: {NOMBRE_EMPRESA}. Uso principal: {caso de uso}",
      "Control de versiones: {tu org en GitHub/GitLab/Bitbucket}",
      "Proveedores cloud: {AWS, GCP, Azure...}",
      "Buckets de confianza: {s3://tu-bucket, gs://tu-otro-bucket}",
      "Dominios internos: {*.internal.tuempresa.com, api.tuempresa.com}",
      "Servicios clave: {Jenkins en ci.tuempresa.com, Artifactory en...}",
      "Contexto adicional: {industria regulada, multi-tenant, requisitos de compliance}"
    ]
  }
}

La comunidad de Claude Code también publica templates listos para usar. En aitmpl.com hay configuraciones reales para stacks frecuentes. Este es un ejemplo típico para un equipo de producto SaaS:

// Template comunidad: stack SaaS web (Next.js + Vercel + Supabase)
// Equipo de producto B2B, ~10 ingenieros, datos de usuarios finales
{
  "autoMode": {
    "environment": [
      "Organización: startup de producto SaaS B2B. Equipo de ingeniería de producto",
      "Control de versiones: github.com/mi-startup y todos sus repositorios",
      "Proveedores cloud: Vercel para frontend y edge functions, Supabase para base de datos y auth",
      "Dominios internos: api.mi-startup.com, *.mi-startup.internal",
      "Servicios clave: Stripe para pagos, Resend para email transaccional, Cloudflare CDN",
      "Contexto adicional: entorno multi-tenant con datos de usuarios finales, revisar permisos antes de operar en producción"
    ]
  }
}

Úsalo como punto de partida y ajusta los dominios, servicios y proveedores a los tuyos. La plantilla de Anthropic cubre los campos; las de la comunidad te muestran cómo queda rellena con un stack real.

No necesitas rellenar todo de golpe. Empieza con la organización y el control de versiones: eso solo ya resuelve los falsos positivos más frecuentes (push a tu propia org de GitHub). Añade dominios y buckets a medida que el clasificador te los bloquee.

Dos advertencias antes de seguir. Primera: este bloque describe endpoints y dominios, no credenciales. No incluyas tokens, contraseñas ni claves de API aquí, aunque intuyas que ayudan al clasificador a autenticarse. Segunda: ser específico va en ambas direcciones. Una entrada como "Dominios de confianza: *.com" es semánticamente equivalente a dar permiso sobre casi cualquier dominio externo. Demasiado vago genera bloqueos; demasiado amplio genera permisividad no intencionada. El punto medio es describir exactamente lo que usas.

Cómo configurar autoMode en cuatro pasos

No escribas las reglas a ciegas. Hay cuatro comandos de la CLI que hacen el proceso mucho más seguro:

Diagrama de flujo con los cuatro pasos para configurar autoMode.environment: primero ejecutar defaults para leer las reglas base, luego pedir a Claude que proponga el bloque, después guardar en el archivo correcto y validar con config, y finalmente auditar con critique si se modificaron allow o soft_deny.
Sigue este orden para configurar el Auto Mode sin eliminar accidentalmente las reglas de seguridad por defecto.

1. Primero, mira qué hay por defecto

claude auto-mode defaults

Este comando imprime en pantalla las reglas que el clasificador usa sin ninguna configuración tuya: qué bloquea por defecto (force push, curl | bash, deploys a producción, borrado masivo en cloud storage) y qué permite por defecto (operaciones locales en tu directorio, instalar dependencias declaradas en tus manifiestos, peticiones HTTP de solo lectura). Lee esto antes de tocar nada.

2. Pídele a Claude que proponga el bloque

Abre una sesión de Claude Code y pídeselo directamente:

Revisa mi proyecto (package.json, Dockerfiles, configuración de CI)
y propón un bloque autoMode.environment para ~/.claude/settings.json
que cubra mi infraestructura real.

Claude analizará tus archivos de configuración y generará entradas específicas para tu proyecto. Revísalas antes de copiarlas: tú conoces tu infraestructura mejor que él.

3. Valida la configuración

Después de guardar los cambios en el archivo de settings, ejecuta:

claude auto-mode config

Esto muestra la configuración efectiva que usará el clasificador: tus settings donde los hayas definido, los valores por defecto en el resto. Si ves algo raro o hay un error de sintaxis en el JSON, aquí lo detectas antes de que afecte a tu sesión.

4. Audita tus reglas personalizadas

claude auto-mode critique

Este es el paso más valioso si has modificado algo más que environment. El comando hace que el clasificador analice tus reglas y te dé feedback directo: entradas ambiguas que podrían generar falsos positivos, reglas redundantes, o huecos de seguridad que has dejado abiertos sin darte cuenta.

Errores comunes al configurar autoMode

Poner el bloque en el archivo equivocado

El error más frecuente: añadir autoMode al .claude/settings.json del repositorio. El clasificador ignora ese archivo expresamente para evitar que repos externos se inyecten sus propias reglas de confianza. Si después de configurarlo todo el clasificador sigue bloqueando lo mismo, lo primero que hay que revisar es en qué archivo pusiste el bloque.

Modificar allow o soft_deny sin copiar los defaults primero

autoMode.environment es aditivo: lo combina con las reglas por defecto sin problema. Pero si también defines allow o soft_deny, reemplazas la lista completa.

Atención: Un soft_deny con una sola entrada elimina todas las reglas de bloqueo por defecto. Force push, curl | bash, deploys a producción. Todo.

Si necesitas personalizar esas secciones, empieza con claude auto-mode defaults, copia las listas completas a tu settings, y luego edita. Nunca empieces desde cero.

Usar patrones técnicos en lugar de lenguaje natural

autoMode.environment no acepta regex ni wildcards. Es texto libre que el clasificador interpreta semánticamente. "*.acme.internal" funciona porque el clasificador entiende que es un patrón de dominio, pero no porque lo evalúe como glob. Escribe con claridad: cuanto más contexto des, mejor distingue el clasificador entre infraestructura tuya y servicios externos.

Checklist de implementación

  • Comprobar que tienes Claude Code v2.x o posterior (claude --version) — consulta las release notes para la versión mínima actual con Auto Mode
  • Verificar que tu cuenta tiene plan Team, Enterprise o API (el Auto Mode no está disponible en Pro o Max)
  • Verificar que la sesión usa Claude Sonnet 4.6 u Opus 4.6 (no disponible con Haiku ni claude-3)
  • Ejecutar claude auto-mode defaults y leer las listas completas antes de tocar nada
  • Añadir el bloque autoMode.environment en ~/.claude/settings.json o en .claude/settings.local.json del proyecto
  • Comprobar que el archivo NO es .claude/settings.json (el que va a git)
  • Ejecutar claude auto-mode config para validar que la configuración se carga correctamente
  • Ejecutar claude auto-mode critique si has definido allow o soft_deny personalizados

Fuentes

  1. Configure permissions — Anthropic Docs — estructura de autoMode.environment, plantilla base, comandos CLI de inspección y advertencias sobre soft_deny/allow.

Preguntas Frecuentes

¿Puedo usar el Auto Mode con un plan gratuito o Pro de Claude?

No. El Auto Mode requiere plan Team, Enterprise o API. Tampoco está disponible en Bedrock, Vertex ni Foundry. Si Claude Code te dice que el Auto Mode no está disponible, casi siempre es por el plan, no por un problema técnico.

¿Puedo poner autoMode.environment en el settings.json del repositorio para compartirlo con mi equipo?

El clasificador no lee el .claude/settings.json compartido del repositorio por diseño. Para distribuir la configuración a todo el equipo, la opción correcta son los managed settings: configuración centralizada que el administrador de la cuenta despliega para todos los desarrolladores del equipo, sin que cada uno edite su archivo personal. Un desarrollador individual puede usar ~/.claude/settings.json o .claude/settings.local.json para su configuración personal.

El clasificador sigue bloqueando cosas aunque haya configurado environment. ¿Qué hago?

Primero, ejecuta claude auto-mode config para confirmar que la configuración se cargó bien. Si la configuración es correcta, el problema suele ser que las entradas de environment son demasiado vagas. “Dominios internos” es menos útil que “Dominio interno de confianza: api.miempresa.com y todos los subdominios bajo *.miempresa.internal”. Sé específico: el clasificador interpreta las frases semánticamente, y el detalle le ayuda a distinguir tu infraestructura de cualquier otro destino.

¿Qué pasa si pongo entradas demasiado amplias en environment?

El clasificador interpreta las frases semánticamente, así que una entrada como "Confío en todos los servicios cloud" no se queda solo en tus proveedores habituales: le dice al clasificador que cualquier petición a cualquier SaaS externo o dominio desconocido es aceptable. Eso elimina precisamente la capa de protección que justifica usar Auto Mode. La regla de ser específico aplica en los dos sentidos: demasiado vago genera falsos positivos, demasiado amplio genera permisividad no intencionada. Si una entrada cubre más de lo que realmente usas, divídela en entradas concretas.

¿Qué pasa si el clasificador me bloquea demasiadas veces?

Si el clasificador bloquea la misma acción 3 veces seguidas, o 20 veces en total durante la sesión, el Auto Mode se pausa automáticamente y Claude Code vuelve a pedirte confirmación manual. Cada acción permitida reinicia el contador de bloqueos consecutivos. Cuando eso pasa con frecuencia, es una señal de que falta contexto en environment, no de que el Auto Mode esté roto.