Auto mode o bypassPermissions en Claude Code: menos avisos no significa acceso sin límites

Si los avisos de permisos interrumpen el trabajo, el punto de partida razonable es Auto mode con reglas deny y ask explícitas. Añade el sandbox de Bash cuando también necesites limitar archivos y red. bypassPermissions no es el siguiente nivel de comodidad: solo tiene sentido cuando un contenedor o una máquina virtual ya es el límite real del daño.

Los dos modos reducen mucho las confirmaciones, pero no delegan la misma autoridad. En Auto mode, otro modelo clasifica la acción antes de ejecutarla. Con bypassPermissions, desaparece la ruta normal de revisión de permisos y seguridad.

Dos terminales silenciosos pueden tener controles opuestos

La documentación actual de modos de permisos explica que Auto mode ejecuta sin avisos rutinarios mientras un clasificador separado revisa las acciones. Puede bloquear cambios que excedan la petición, infraestructura que no reconoce, operaciones destructivas o acciones que parezcan inducidas por contenido hostil leído por Claude. Una regla ask explícita sigue solicitando confirmación, y permissions.deny se aplica antes del clasificador en todos los modos.

bypassPermissions desactiva los avisos y controles ordinarios para que las tool calls se ejecuten de inmediato, incluidas escrituras en rutas protegidas. Estas dos formas de inicio son equivalentes:

bash
claude --permission-mode bypassPermissions
claude --dangerously-skip-permissions

“Omitir permisos” tampoco significa que desaparezca cada invariante del producto. Conservan un tratamiento específico las reglas ask explícitas, los conectores que la organización obliga a confirmar, las herramientas que requieren interacción del usuario, los borrados rm/rmdir de rutas críticas y algunas protecciones de mensajería entre sesiones. Las reglas deny también siguen vigentes. Son excepciones que precisan el contrato; no convierten bypass en un modo protector. Anthropic indica que no ofrece protección frente a prompt injection ni acciones no deseadas.

Auto mode tampoco garantiza seguridad. El clasificador toma decisiones contextuales y puede omitir un riesgo o bloquear una acción válida. Una aprobación no demuestra que el código sea correcto, que el cambio tenga autorización empresarial ni que el resultado final cumpla la tarea.

Decide por el radio de daño, no por la duración

Una migración de producción de cinco minutos puede requerir mucha más autoridad que una batería local de pruebas durante toda la noche. Antes de escoger, responde con recursos concretos:

1. ¿Qué archivos, redes y recursos cloud alcanzaría un comando incorrecto?
2. ¿Qué credenciales existen y qué puede modificar cada una?
3. ¿Puede destruirse y reconstruirse el entorno sin recuperar el host?
4. ¿Queda un checkpoint humano antes de una acción irreversible o externa?

Para un repositorio propio donde revisarás el diff y las pruebas, Auto mode suele ser el equilibrio útil. Reduce la fatiga de aprobación sin eliminar el revisor contextual.

Para código desconocido, datos personales, infraestructura de producción o una intención todavía cambiante, usa Manual o Plan. En ese escenario hace falta criterio humano, no más automatización.

En CI con un conjunto pequeño y fijo de comandos, dontAsk puede ofrecer un contrato mejor: ejecuta solo herramientas preaprobadas y rechaza el resto. Una allowlist cerrada es más fácil de auditar que decisiones contextuales cuando la superficie ya está definida.

Usa bypassPermissions únicamente si el aislamiento externo es la barrera de seguridad. El punto de partida oficial es un contenedor, VM o dev container sin acceso a Internet. Ejecuta como usuario no root, no montes el home ni credenciales del host, comparte solo la copia de trabajo y un directorio de resultados, y haz el entorno desechable. En Linux y macOS, Claude Code rechaza bypass bajo root o sudo fuera de un sandbox reconocido, pero esa comprobación no sustituye al contenedor.

Si el problema real es que un proceso sobreviva al cierre del terminal, al reposo o a una sesión reanudada, los permisos son solo una parte. La guía de tareas largas en Claude Code separa runtime, estado duradero, evidencia de finalización y recuperación.

Coloca Auto mode en un ámbito que sí se aplique

Para una sola sesión de terminal:

bash
claude --permission-mode auto

Para establecerlo como valor personal de inicio en terminal, usa ~/.claude/settings.json:

json
{
  "permissions": {
    "defaultMode": "auto",
    "deny": [
      "Bash(git push --force *)",
      "Bash(terraform destroy *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(terraform apply *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true
  }
}

El contrato actual de terminal ignora defaultMode: "auto" en .claude/settings.json y .claude/settings.local.json del repositorio. Así, un proyecto descargado no puede activar Auto mode por sí mismo. VS Code y otras interfaces tienen controles de modo inicial distintos, por lo que debes comprobar la superficie que usas.

Adapta los ejemplos deny y ask a tus comandos y destinos con la sintaxis oficial de permisos. Una allow rule demasiado amplia puede aprobar argumentos peligrosos antes de que el clasificador los vea. Si una acción nunca debe ejecutarse, ponla en permissions.deny administrado.

El contexto autoMode.environment puede describir repositorios, dominios internos, buckets, registros de paquetes y destinos sensibles de confianza. No deduzcas la precedence leyendo un solo archivo: inspecciona la configuración combinada.

bash
claude auto-mode config

claude auto-mode defaults muestra las reglas incorporadas y claude auto-mode critique ayuda a detectar reglas personalizadas ambiguas. La disponibilidad, modelo, proveedor, versión, plan y valor inicial son datos volátiles: que exista una configuración no prueba que Auto esté disponible en esa sesión.

El modo aprueba; el aislamiento limita el alcance

Auto mode responde “quién aprueba la acción”. El sandbox de Bash responde “qué archivos y destinos de red puede alcanzar Bash y sus procesos hijos después de la aprobación”. Son capas distintas.

El sandbox integrado funciona en macOS, Linux y WSL2; Windows nativo necesita WSL2. Una configuración que falle cerrada debería:

• permitir escrituras solo en el repositorio y el temporal de sesión;
• incluir únicamente los dominios necesarios en la allowlist de red;
• denegar o enmascarar SSH, credenciales cloud y tokens privilegiados;
• usar allowUnsandboxedCommands: false para impedir reintentos en el host;
• usar failIfUnavailable: true cuando no deba continuar sin sandbox.

El sandbox cubre Bash y sus procesos hijos, no todas las herramientas de Claude Code. En una ejecución bypass sin supervisión, el contenedor o la VM sigue siendo la frontera final. El modo decide quién autoriza; el aislamiento decide qué puede dañar una acción autorizada.

Comprueba el estado efectivo antes de ausentarte

La disponibilidad de Auto mode y el modo inicial varían con la versión, plan, modelo, proveedor, feature flags, política de organización e interfaz. Comprueba el estado vivo:

1. El indicador de modo; en CLI, Shift+Tab recorre los modos presentes en esa sesión.
2. /permissions para allow, ask, deny y denegaciones recientes efectivas.
3. claude auto-mode config para el contexto combinado del clasificador.
4. /sandbox para filesystem, network, mode y unsandboxed retry.

Tras bloqueos repetidos, una sesión interactiva puede volver a pedir confirmación humana. En un -p no interactivo sin permission prompt tool, la acción denegada no se ejecuta, pero Claude puede continuar con otros pasos. Un proceso activo no es evidencia de éxito: define una condición observable de finalización y un artefacto de fallo.

Elige Auto mode cuando confíes en la dirección pero quieras conservar un revisor; dontAsk cuando el contrato sea una allowlist fija; Manual o Plan cuando haga falta juicio humano. Considera bypassPermissions solo cuando host, Internet, credenciales y estado persistente ya estén fuera del alcance del agente.