Usar Auto Mode en Claude Code con seguridad, en 10 pasos sin comandos suicidas

Si llevas un tiempo usando Claude Code, conoces ese momento: estás ahí dándole solo a Enter, porque cada cambio de archivo y cada comando de bash quiere confirmarse por separado. Auto Mode te quita justo eso. Claude aprueba sus propias tool calls, mientras en segundo plano un control de seguridad verifica si la acción encaja con lo que en realidad querías. Suena a acelerar a fondo sin freno. Pero no lo es, si entiendes qué bloquea el modo y qué dos redes tiendes tú mismo por debajo.

Importante de entrada: Auto Mode no es un modo en el que te metes automáticamente. El modo de partida de cada sesión sigue siendo Manual, es decir, preguntar antes de cada acción. Auto Mode lo activas a propósito, con Shift+Tab en la sesión o de forma permanente con defaultMode: "auto" en los ajustes. Ya está ampliamente disponible, pero no lo tratas como un set-and-forget para repos de producción. Repasamos diez pasos. Primero la ubicación, luego la activación, luego los mecanismos de protección, luego tu propia red por debajo, y al final la pregunta de cuándo activarlo siquiera.

1. Entender qué hace Auto Mode de verdad

Auto Mode es uno de varios modos de permisos en Claude Code. La descripción en la documentación oficial es escueta y precisa: aprueba tool calls automáticamente, con controles de seguridad en segundo plano que verifican que las acciones encajan con tu petición. Esa es la diferencia decisiva frente a bypassPermissions. Bypass sencillamente ya no pregunta. Auto tampoco pregunta, pero comprueba cada acción contra lo que en realidad encargaste.

En el día a día significa: dices "constrúyeme el formulario de login", Claude edita archivos y ejecuta npm run build sin preguntar. Pero si Claude de repente empieza a borrar una base de datos o a tirar tu historial de Git local, salta el control en segundo plano. Eso no es un cheque en blanco, es otro tipo de freno.

2. Tener el mapa de modos en la cabeza

Antes de activar Auto Mode, ubícalo. Claude Code tiene varios modos de permisos, fijados con defaultMode en el settings.json. default pregunta en el primer uso de cada herramienta. acceptEdits acepta ediciones de archivos y comandos inofensivos del sistema de archivos como mkdir, touch, mv, cp automáticamente, pero solo para rutas en tu directorio de trabajo. plan es Plan Mode, o sea solo leer y shell de solo lectura, sin cambios en tu código. auto es nuestro tema. bypassPermissions se salta todos los prompts salvo las ask rules forzadas, e incluso ahí rm -rf / queda como freno de emergencia con confirmación. dontAsk le da la vuelta y rechaza todo lo que no se haya permitido antes.

El orden mental correcto de prudente a atrevido es, por tanto: plan, default, acceptEdits, auto, bypassPermissions. Auto está bien adelante en la zona roja, pero no del todo. Quien solo quiere ediciones de archivos sin confirmación y no necesita plenos poderes de bash, suele estar mejor servido con acceptEdits.

3. Activar Auto Mode a propósito

El modo lo cambias dentro de una sesión con el conmutador de modo de permisos en la interfaz. De forma permanente lo fijas con defaultMode en tus user settings, por ejemplo:

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

Mi consejo, con un matiz importante: Auto Mode solo se puede activar de forma permanente a través de tus user settings (~/.claude/settings.json). Un defaultMode: "auto" en un archivo de ajustes de proyecto o local Claude Code lo ignora a propósito, justo para que ningún repo ajeno que clones te cuele el modo. Quien no quiera tenerlo siempre puesto, deja los user settings en Manual y en su lugar cambia por sesión con Shift+Tab. Un Auto Mode fijado globalmente te muerde justo cuando cambias a un repo ajeno o de producción y se te ha olvidado. Para la mayoría, cambiar por sesión es por eso la opción más segura.

4. No confundir el control en segundo plano con magia

El control de seguridad verifica si una acción encaja con tu petición. Eso está bien, pero es una heurística, no un contrato. Si tu propia petición estaba formulada de forma peligrosa ("ordena el repo, borra lo que no haga falta"), un comando destructivo puede encajar perfectamente con tu encargo y se deja pasar.

Consecuencia para tu estilo de prompt en Auto Mode: formula con precisión. "Construye la función X en el archivo Y" es mejor que "deja el proyecto limpio". Cuanto más vago sea tu encargo, mayor el margen que el control deja pasar como legítimo. El modo es tan seguro como precisa sea tu instrucción.

5. Saber qué bloquea Auto Mode de todos modos

Aquí se pone concreto, y son reglas verificadas del changelog. Auto Mode bloquea comandos de Git destructivos si no has dicho explícitamente que el trabajo local puede irse. En concreto están afectados git reset --hard, git checkout -- ., git clean -fd y git stash drop. git commit --amend se bloquea si el commit no lo hizo el agente en esta sesión, para que nadie te reescriba un historial ajeno. Y terraform destroy, pulumi destroy así como cdk destroy están bloqueados mientras no hayas nombrado el stack concreto.

Esa es la lista incorporada de comandos suicidas que el modo ataja por ti. En la práctica significa: Auto Mode puede construir y probar, pero tu estado sin commit y tu infraestructura están protegidos contra los accidentes más obvios. Aun así, no te fíes solo de eso, para eso viene el Paso 6.

6. Tender deny rules como red dura por debajo

La lista de protección del Paso 5 es fija. Tu propia red la construyes con deny rules en los permisos. Importante saberlo: las reglas se evalúan en el orden deny, luego ask, luego allow. La primera coincidencia gana. Así que una deny rule siempre prevalece, incluso contra una allow rule más específica. Eso convierte a deny en tu herramienta más fiable.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Read(./.env)",
      "Bash(docker system prune *)"
    ]
  }
}

Un detalle que muchos pasan por alto: una deny rule con solo el nombre de la herramienta como Bash elimina la herramienta por completo del contexto de Claude, Claude ya no la ve. Una deny rule con patrón como Bash(rm *) deja la herramienta ahí y solo bloquea las llamadas que coinciden. Para Auto Mode normalmente quieres la variante con patrón, para que Claude pueda seguir ejecutando comandos normales y solo se frenen los peligrosos.

7. Aislar Auto Mode en un worktree

La mejor red es la separación espacial. Si Auto Mode corre en su propio worktree de Git, una acción que se cuele puede afectar como mucho a ese worktree, no a tu rama principal. Creas un worktree, arrancas Claude ahí en Auto Mode, y al final fusionas a propósito solo lo que está limpio. Si algo sale mal, borras el worktree y tu original nunca se tocó.

Cómo va el setup en detalle está en el playbook Claude Code con Git worktrees y en Sesiones paralelas de Claude con worktrees. La combinación de Auto Mode más worktree es para mí la única configuración en la que dejo correr Auto Mode en un repo serio.

8. La sandbox como segunda capa de separación

El worktree separa el riesgo de Git. La sandbox de bash separa el riesgo del sistema. Cuando Claude aprueba sus propios comandos de bash en Auto Mode, quieres que esos comandos corran en un entorno restringido y no lleguen sin trabas a todo tu sistema. El setup para ello está paso a paso en el playbook Configurar la sandbox de bash de Claude Code.

Worktree más sandbox más deny rules es el triple aseguramiento. Cada capa ataja un tipo distinto de error. Suena a mucho, pero se configura una vez y luego es de forma permanente tu entorno estándar para trabajar sin supervisión.

9. Prohibir Auto Mode por completo a otros

Si trabajas en un equipo o aseguras un entorno en el que nadie debe usar Auto Mode, hay un interruptor duro para ello. En los ajustes pones permissions.disableAutoMode en "disable". De forma análoga, permissions.disableBypassPermissionsMode bloquea el modo bypass. Lo más eficaz es hacerlo en Managed Settings, porque ahí no lo pueden sobrescribir desarrolladores individuales.

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

Esa es la respuesta correcta cuando alguien pregunta "cómo evito que un junior desactive por descuido toda la prudencia". No lo regules mediante la confianza, mediante Managed Settings.

10. Saber cuándo activas Auto Mode y cuándo no

Auto Mode es fuerte para tareas con muchos pasos pequeños repetidos en un repo en el que confías. Un refactor mayor con un patrón claro, poner la test suite en verde, llevar una migración por muchos archivos. Ahí te ahorra un fastidio de verdad y el control en segundo plano más tus deny rules atajan los patinazos gordos.

En cambio, manos fuera con código de producción sin worktree, con encargos vagos, con todo lo que toque infraestructura o bases de datos, y con repos ajenos cuyo contenido no abarcas. Y como Auto Mode te quita las aprobaciones: vigila las sesiones al principio en vez de ponerte a hacer otra cosa a la vez. La confianza la construyes mirando, no apartando la vista.

Qué viene ahora

Si Auto Mode te resulta demasiado atrevido, Plan Mode es el contrapunto tranquilo, ahí Claude solo lee y propone antes de que pase nada. Para ello lee Usar bien Plan Mode. Si el tema de la seguridad te interesa en general, Confused Deputy Audit para Claude Code es el siguiente paso. Y quien quiera vigilar los costes al trabajar sin supervisión encontrará la rutina en Claude Code Cost Controls. Quien aún no tenga un setup de Git limpio como cinturón de seguridad, lo mejor es empezar por el Git para IA Quickstart, porque sin disciplina de commits, el mejor sistema de permisos te sirve de poco.

Source

• Modos de permisos y orden de deny rules: Configure permissions, Claude Code Docs
• Reglas de protección de Auto Mode para Git, Terraform, Pulumi, CDK: Claude Code Changelog