Saltar al contenido principal

Permisos y modos de permiso

Intermedio
What you'll learn
  • Qué significan los tres veredictos de permiso (allow / ask / deny)
  • Cómo las reglas de permiso asocian una herramienta con un patrón
  • Los seis modos de permiso y cuándo usar cada uno
  • Por qué el modo auto es ahora el modo de inicio de las sesiones interactivas, y cómo desactivarlo
  • Cómo el modo auto sustituye las confirmaciones por un clasificador de seguridad
  • Cómo construir una allowlist inicial sensata que reduzca las confirmaciones sin perder seguridad
  • Dónde guardar las reglas de permiso del proyecto y las personales

Los permisos deciden qué puede hacer Claude Code sin detenerse a preguntarte. Si los ajustas bien, ganas fluidez sin perder el control; si los ajustas mal, o lo apruebas todo sin mirar o te ahogas en confirmaciones.

Los tres veredictos​

Cada acción posible se resuelve en uno de estos:

Pulsa Intro o Espacio para girar la tarjeta. Usa las flechas izquierda y derecha para moverte entre las tarjetas.Término mostrado.
1 / 3

Las reglas suelen asociar una herramienta con un patrón, por ejemplo allow Bash(npm run test:*) o deny Read(./.env).

Permitir una herramienta + patrón

Bash(npm run test:*)

Denegar una herramienta + patrón

Read(./.env)

Modos de permiso​

Un modo fija la postura general de una sesión. Hay seis. Recorre los más comunes con Shift+Tab, o define permissions.defaultMode en la configuración.

ModoSe ejecuta sin preguntarÚsalo cuando
default (se muestra como Manual)Solo lecturasTrabajo diario, cambios delicados
acceptEditsLecturas, ediciones de archivos, comandos habituales del sistema de archivosUna sesión de edición de confianza y bien acotada
planLecturas, más los comandos aprobados por el clasificador cuando el modo auto está disponible; nunca edita tu código fuenteTareas grandes o arriesgadas: ver Plan Mode
auto (el modo de inicio de las sesiones interactivas desde la v2.1.283)Todo, filtrado por un clasificador de seguridadTareas largas donde el verdadero riesgo es la fatiga de confirmaciones
dontAskLecturas de archivos en tus directorios de trabajo y herramientas preaprobadas; todo lo que pediría confirmación se deniegaCI y scripts blindados
bypassPermissionsTodo, sin comprobacionesSolo sandboxes/contenedores: nunca en una máquina con secretos

El modo auto es ahora el predeterminado de Claude Code​

Desde Claude Code v2.1.283, auto es el modo de inicio integrado de las sesiones interactivas en terminal y VS Code en todos los planes y proveedores. En versiones anteriores era el predeterminado de las sesiones nuevas solo en los planes Pro, Max y Team, a partir del 14 de agosto de 2026. La justificación de Anthropic (basada en sus propias pruebas con más de 1.000 usuarios de pago): el clasificador detectó el 89 % de las acciones dañinas frente al 13,6 % de la revisión manual, porque los usuarios, ya habituados, aceptaban alrededor del 97 % de las confirmaciones manuales sin leerlas.

Dos excepciones preservan la intención:

  • Si tú defines permissions.defaultMode en tu configuración de usuario, se mantiene a menos que aceptes un aviso único de cambio en la aplicación.
  • Si tu organización gestiona el valor predeterminado (configuración gestionada de Team/Enterprise), no cambia nada automáticamente.

Siempre puedes cambiar de modo a mitad de sesión con Shift+Tab. Un cambio relacionado que ya está en vigor en esos planes: las llamadas al clasificador que hace el modo auto ya no cuentan para tus límites de uso.

Activarlo antes (antes del 14 ago): establece auto como predeterminado

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "auto"
}
}

Mantener el comportamiento anterior con confirmaciones después del 14 ago

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "default"
}
}

Cómo funciona realmente el modo auto​

auto es el punto medio entre pedir confirmación para todo y desactivar la seguridad. En lugar de preguntarte, un modelo clasificador independiente revisa cada acción antes de ejecutarla y bloquea todo lo que escale más allá de lo que pediste, toque una infraestructura que no reconoce o parezca impulsado por contenido hostil que Claude acaba de leer. Las reglas ask explícitas siguen deteniéndose y preguntándote.

Bloquea cosas como curl | bash, force push, despliegues y migraciones en producción, rm -rf sobre variables sin resolver, manipulación de la transcripción, comandos git destructivos que descartan trabajo sin confirmar y el envío de secretos a destinos externos, mientras deja pasar el trabajo rutinario (ediciones locales, instalación de dependencias declaradas, HTTP de solo lectura, push a tu propia rama). Si bloquea la misma acción repetidamente, el modo auto se pausa y te devuelve las confirmaciones.

El modo auto no es una garantía de seguridad: reduce las confirmaciones, pero no elimina la necesidad de revisar las operaciones delicadas. La disponibilidad depende de tu plan, del modelo y (en Team/Enterprise) de un interruptor del administrador. Si trabajas de verdad sin supervisión (cron, sesiones en la nube, CI), combínalo con Hardening Autonomous Runs: auto sigue sin ser bypassPermissions.

Watch out
  • bypassPermissions pertenece a un sandbox. Trabajar en tu máquina real con todas las confirmaciones desactivadas es como un agente acaba tocando algo que no debería. Resérvalo para entornos desechables; si lo que realmente quieres es menos confirmaciones, usa el modo auto. Consulta Hardening Autonomous Runs en /docs/security/hardening-autonomous-runs.

Una allowlist inicial sensata​

El objetivo: preautorizar lo seguro y repetitivo; mantener lo destructivo en ask o deny.

Guided walkthrough1 of 3
  1. Leer archivos, ejecutar tus comandos de test/lint/build, git status/diff.

Guarda las reglas del proyecto en settings.json (compartido) y tus ajustes personales en settings.local.json.

Pro tip
  • Deja que aprenda de tus confirmaciones: aprueba el mismo comando seguro unas cuantas veces y sabrás exactamente qué añadir a tu allowlist, convirtiendo las confirmaciones repetidas en una regla de una sola vez.
Key takeaways
  • Tres veredictos: allow (sin confirmación), ask (por defecto: pausa y confirma), deny (nunca).
  • Las reglas asocian una herramienta con un patrón, como Bash(npm run test:*) o Read(./.env).
  • Seis modos fijan la postura de la sesión: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
  • Desde la v2.1.283, auto es el modo de inicio de las sesiones interactivas en terminal y VS Code en todos los planes; un defaultMode que hayas definido tú se mantiene, y los valores predeterminados gestionados por la organización no se tocan.
  • El modo auto filtra cada acción con un clasificador de seguridad en lugar de preguntarte: es la herramienta contra la fatiga de confirmaciones, no bypassPermissions.
  • Construye una allowlist: allow para lo seguro y repetitivo, ask para el riesgo medio, deny para lo destructivo.
  • Las reglas compartidas van en settings.json; los ajustes personales en settings.local.json.

Compruébalo tú mismo

0/6
  1. ¿Qué hace el veredicto predeterminado 'ask' ante una acción que no está permitida ni denegada de forma explícita?
  2. ¿Qué modo de permiso es seguro SOLO en sandboxes o contenedores, nunca en una máquina con secretos?
  3. Quieres muchas menos confirmaciones de permiso en una tarea larga, pero sin perder una red de seguridad. ¿Qué modo?
  4. ¿Dónde debes guardar las reglas de permiso compartidas del proyecto y dónde los ajustes personales?
  5. ¿Cuál de estos elementos pertenece a la lista 'deny' de una allowlist inicial sensata?
  6. El 14 de agosto de 2026, ¿qué ocurre en un plan Pro si ya habías definido permissions.defaultMode como 'default' en tu configuración de usuario?

Siguiente​