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

> Compara Auto mode y bypassPermissions por quién revisa las acciones, controles restantes, aislamiento y comportamiento de ejecuciones sin supervisión.

- Source: https://www.aifreeapi.com/es/posts/claude-code-auto-mode-vs-bypass-permissions
- Language: es
- Published: 2026-08-20
- Updated: 2026-08-20
- Publisher: AI Free API (https://www.aifreeapi.com)

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](https://code.claude.com/docs/es/permission-modes) 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.

| Pregunta operativa | Auto mode | `bypassPermissions` |
|---|---|---|
| Quién revisa una acción ordinaria | Un clasificador separado | Nadie en el flujo ordinario |
| Avisos rutinarios | Se eliminan; ask sigue preguntando | Se eliminan; quedan excepciones documentadas |
| Reglas deny deterministas | Se aplican | Se aplican |
| Escritura en rutas protegidas | No se aprueba automáticamente en general | Se ejecuta sin el control ordinario de ruta protegida |
| Entorno previsto | Trabajo cuya dirección confías, con defensa en profundidad | Contenedor, VM o dev container aislado y sin Internet |
| Aislamiento del SO | El modo no lo proporciona | El modo no lo proporciona |

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](/es/posts/claude-code-long-running-tasks) 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.

![Ámbitos de configuración de Auto mode y cuatro comprobaciones del estado efectivo](https://www.aifreeapi.com/posts/es/claude-code-auto-mode-vs-bypass-permissions/img/effective-config.webp)

Adapta los ejemplos deny y ask a tus comandos y destinos con la [sintaxis oficial de permisos](https://code.claude.com/docs/es/permissions). 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](https://code.claude.com/docs/es/sandboxing) 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.

![Comportamiento interactivo y no interactivo después de que el clasificador deniegue una acción](https://www.aifreeapi.com/posts/es/claude-code-auto-mode-vs-bypass-permissions/img/denied-actions.webp)

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.