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 una regla de permiso coincide con una herramienta más un patrón
  • Los seis modos de permiso y cuándo usar cada uno
  • Cómo el modo auto sustituye las preguntas por un clasificador de seguridad
  • Cómo construir una lista de permitidos inicial sensata que reduzca las preguntas sin perder seguridad
  • Dónde guardar las reglas de permiso del proyecto frente a las personales

Los permisos deciden qué puede hacer Claude Code sin detenerse a preguntarte. Ajústalos bien y obtienes fluidez sin perder el control; ajústalos mal y o bien apruebas todo a ciegas o te ahogas en preguntas.

Los tres veredictos​

Cada posible acción 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 coincidir con una herramienta más un patrón, p. ej. permitir Bash(npm run test:*) o denegar Read(./.env).

Permitir una herramienta + patrón

Bash(npm run test:*)

Denegar una herramienta + patrón

Read(./.env)

Modos de permiso​

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

ModoSe ejecuta sin preguntarÚsalo cuando
default (mostrado como Manual)Solo lecturasTrabajo del día a día, cambios sensibles
acceptEditsLecturas, ediciones de archivos, comandos habituales del sistema de archivosUna sesión de edición de confianza y bien acotada
planSolo lecturas; propone, nunca editaTareas grandes/arriesgadas — ver Modo Plan
autoTodo, filtrado por un clasificador de seguridadTareas largas donde el riesgo real es la fatiga por tantas preguntas
dontAskSolo herramientas preaprobadas; todo lo demás se deniegaCI y scripts blindados
bypassPermissionsTodo, sin comprobacionesSolo sandboxes/contenedores — nunca en una máquina con secretos

Modo auto​

auto es el punto intermedio entre preguntar por todo y desactivar la seguridad. En lugar de preguntarte, un modelo clasificador independiente revisa cada acción antes de ejecutarla y bloquea cualquier cosa que vaya más allá de lo que pediste, que toque infraestructura que no reconoce o que parezca impulsada 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, y el envío de secretos a endpoints externos — mientras deja pasar sin fricción el trabajo rutinario (ediciones locales, instalar dependencias declaradas, HTTP de solo lectura, hacer push a tu propia rama). Si bloquea la misma acción repetidamente, el modo auto se detiene y te devuelve el control mediante preguntas.

El modo auto no es una garantía de seguridad: reduce las preguntas, no elimina la necesidad de revisar las operaciones sensibles. Su disponibilidad depende de tu plan, del modelo y (en Team/Enterprise) de un ajuste del administrador.

Watch out
  • bypassPermissions pertenece a un sandbox. Ejecutar con todas las preguntas desactivadas en tu máquina real es la forma en que un agente acaba tocando algo que no debería. Resérvalo para entornos desechables — si lo que de verdad quieres son menos preguntas, usa el modo auto. Consulta Endurecer ejecuciones autónomas en /docs/security/hardening-autonomous-runs.

Una lista de permitidos sensata para empezar​

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 las anulaciones personales en settings.local.json.

Pro tip
  • Deja que aprenda de tus preguntas: aprueba el mismo comando seguro unas cuantas veces y sabrás exactamente qué añadir a tu lista de permitidos — convirtiendo preguntas repetidas en una regla puntual.
Key takeaways
  • Tres veredictos: allow (sin preguntar), ask (por defecto — pausa y confirma), deny (nunca).
  • Las reglas coinciden con una herramienta más un patrón, como Bash(npm run test:*) o Read(./.env).
  • Seis modos establecen la postura de la sesión: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
  • El modo auto filtra cada acción con un clasificador de seguridad en lugar de preguntarte: esa es la herramienta contra la fatiga por preguntas, no bypassPermissions.
  • Construye una lista de permitidos: permite lo seguro + repetitivo, pregunta para lo de riesgo medio, deniega lo destructivo.
  • Las reglas compartidas van en settings.json; las anulaciones personales en settings.local.json.

Ponte a prueba

0/5
  1. ¿Qué hace el veredicto por defecto 'ask' ante una acción que no está explícitamente permitida ni denegada?
  2. ¿Qué modo de permiso es seguro SOLO en sandboxes o contenedores, nunca en una máquina con secretos?
  3. Quieres muchas menos preguntas de permiso en una tarea larga, pero sin renunciar a una red de seguridad. ¿Qué modo?
  4. ¿Dónde deberías guardar las reglas de permiso compartidas del proyecto frente a las anulaciones personales?
  5. ¿Cuál de estos pertenece a la lista de 'deny' en una lista de permitidos inicial sensata?

Siguiente​