[Claude Code #3] Resumen de permisos: /permissions y ciclo de modos

Al usar herramientas de codificación con IA surge un dilema: pedir permiso cada vez resulta tedioso, pero abrirlo todo da miedo por git push y rm -rf.

Claude Code resuelve este equilibrio mediante reglas de permisos. Algunos comandos pasan en silencio, otros requieren confirmación y otros se bloquean por completo.

El modo de planificación que vimos en Claude Code, parte 2 también funciona sobre este sistema de permisos. En esta parte reuniremos la visión completa.

Comportamiento básico: ¿qué solicita confirmación?

Según Documentación oficial de permisos, cada tipo de herramienta tiene reglas predeterminadas distintas.

Las herramientas de solo lectura, como leer archivos o buscar, funcionan sin aprobación dentro del directorio de trabajo.

En principio, los comandos de shell requieren aprobación. La excepción es el conjunto integrado de comandos de solo lectura.

Las modificaciones de archivos siempre solicitan confirmación. Aunque elijas «No volver a preguntar», la opción se restablece al terminar la sesión. En cambio, «No volver a preguntar» para comandos de shell se guarda como regla por repositorio y permanece en las sesiones siguientes.

Consultar reglas con /permissions

Si introduces /permissions durante la sesión, se abre la lista de reglas aplicadas. También muestra de qué settings.json procede cada regla.

Hay tres tipos de reglas.

• allow: permite la ejecución sin preguntar
• ask: solicita confirmación en cada intento
• deny: bloquea la ejecución por completo

El orden de evaluación lo determina todo

¿Qué ocurre cuando se solapan las reglas? El orden es deny → ask → allow, y gana la primera regla que coincide.

Lo importante es que la especificidad no cambia el orden. Si añades Bash(aws *) a deny, se bloqueará aunque escribas Bash(aws s3 ls) con todo detalle en allow.

Las reglas deny no admiten excepciones. No puedes configurar «bloquear todo aws, pero permitir consultas de s3»; debes dividir las reglas en ámbitos más pequeños.

Además, si escribes solo el nombre de una herramienta en deny, sin paréntesis (por ejemplo, Bash), la herramienta desaparece por completo del contexto de Claude. Una regla con ámbito limitado, como Bash(rm *), conserva la herramienta y bloquea solo esa llamada.

Repaso rápido de la sintaxis de las reglas

Las reglas tienen la forma 도구 o 도구(지정자). Las reglas de Bash admiten el comodín * y su posición es libre.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(* --version)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)"
    ]
  }
}

Si hay un espacio antes del asterisco al final del comando (Bash(ls *)), se respeta el límite de palabra. Coincide con ls -la, pero no con lsof. Sin espacio, Bash(ls*) también coincide con lsof.

En comandos compuestos como git status && npm test, cada subcomando debe cumplir una regla. Aunque permitas Bash(safe-cmd *), safe-cmd && other-cmd no podrá pasar.

Las reglas de rutas de archivos solo comprueban Read(경로) y Edit(경로). Usan la sintaxis de patrones de gitignore. Si escribes Write(docs/**), se ignora; debes escribir Edit(docs/**).

Como extra, Read deny también bloquea la edición y escritura de esa ruta. Con el único Read(./.env) del ejemplo se bloquean tanto la lectura como la modificación.

Modos de permisos: ciclo con Shift+Tab

Si las reglas son un ajuste preciso, el modo de permisos define la orientación de toda la sesión.

Cada vez que pulsas Shift+Tab, los modos rotan así: default (aprobación manual) → acceptEdits (aprobación automática de ediciones) → plan (modo de planificación). El modo de planificación se trató en la parte anterior.

Según Documentación oficial de los modos de permisos, el modo auto también entra en el ciclo si cumples las condiciones de cuenta y plan. Un modelo clasificador filtra solo las acciones peligrosas y no pregunta por las demás. Aun así, las reglas ask explícitas siguen forzando la confirmación.

Como referencia, Según el anuncio oficial establece que, desde el 14 de agosto de 2026, las sesiones nuevas de los planes Pro, Max y Team usan auto como valor predeterminado.

Prioridad entre archivos de configuración

Las reglas pueden distribuirse entre varios niveles de settings.json: configuración personal global (~/.claude/), proyecto (.claude/settings.json), configuración solo local y configuración administrada por la organización.

El principio que explica Documentación oficial sobre la prioridad de configuración es sencillo: si deny coincide en cualquier nivel, allow de otro nivel no puede revertirlo.

Puedes bloquear con deny personal algo permitido por el proyecto, y también al contrario. El deny de la configuración administrada por la organización tampoco puede anularse con una opción de línea de comandos.

Las reglas las cumple la herramienta, no el modelo

Por último, hay un punto que se presta a confusión.

Escribir «no hagas git push» en CLAUDE.md es una petición, no una obligación. Si el modelo olvida la instrucción o juzga mal, puede saltársela.

Las reglas de permisos son distintas. El cliente de Claude Code las aplica mecánicamente, sin importar el criterio del modelo. Lo que deba bloquearse de forma obligatoria debe ir en una regla deny, no en CLAUDE.md.

Resumen

La estructura del sistema de permisos tiene tres elementos: reglas allow, ask y deny; el orden de evaluación deny → ask → allow; y el modo de permisos que define la orientación de la sesión.

La estrategia básica es permitir con allow los comandos seguros que usas con frecuencia para reducir la fatiga de confirmaciones, y bloquear firmemente los peligrosos con deny.

En la próxima parte trataremos el conjunto de tres mecanismos /resume, /branch y /fork para continuar y dividir las conversaciones.

Fuentes y criterios de verificación

• Documentación oficial de Claude Code — Configure permissions (Anthropic, comprobado el 13-08-2026)
• Documentación oficial de Claude Code — Choose a permission mode (Anthropic, comprobado el 13-08-2026)

Seguir leyendo

Serie de Claude Code

• Parte anterior: [Claude Code #2] Modo de planificación /plan: acordar el diseño antes de modificar
• Parte anterior: [Claude Code #1] Empezar con /init y la generación automática de CLAUDE.md

Temas relacionados

• [Diseño de agentes #1] ¿Qué es la ingeniería de arneses? Lo que viene después de los prompts