Sección de IA

Modos de permisos de Claude Code

Los modos de permiso controlan si Claude pregunta antes de actuar. Diferentes tareas requieren diferentes niveles de autonomía: quieres supervisión total para trabajo sensible, pocas interrupciones para un refactor largo, o acceso de solo lectura mientras exploras un código nuevo.

La decisión clave es: ¿cuánto confías en lo que Claude va a hacer?

Modos disponibles

Claude Code ofrece 6 modos, cada uno con un equilibrio distinto entre autonomía y supervisión.

1. El modo default permite a Claude únicamente leer archivos sin preguntar. Es el modo adecuado para dar los primeros pasos, realizar trabajo sensible o explorar repositorios desconocidos, ya que garantiza que cualquier modificación requiere aprobación explícita.
2. El modo acceptEdits permite leer y editar archivos sin interrupciones. Resulta ideal cuando estás iterando sobre código que revisas activamente, porque puedes mantener un flujo de trabajo ágil sin renunciar a la revisión manual de los cambios.
3. El modo plan limita a Claude a leer archivos, sin capacidad para editar ni ejecutar. Es perfecto para explorar un codebase nuevo o planificar un refactor antes de tocar nada, ya que fuerza una fase de análisis previa a la acción.
4. El modo auto habilita todas las acciones con verificación del clasificador en segundo plano. Está pensado para tareas largas en las que quieres reducir la fatiga de aprobaciones, delegando el control a un sistema automático que filtra las acciones sospechosas.
5. El modo dontAsk solo ejecuta herramientas pre-aprobadas explícitamente. Es la opción recomendada para pipelines CI/CD y scripts automatizados, donde el conjunto de acciones permitidas debe estar cerrado y definido de antemano.
6. Finalmente, el modo bypassPermissions permite todo sin verificaciones. Solo debe usarse en contenedores o máquinas virtuales aisladas, nunca en tu máquina principal, por el riesgo evidente que conlleva operar sin controles.

Cómo cambiar de modo

Durante una sesión: pulsa Shift+Tab para ciclar entre los modos siguiendo la secuencia default → acceptEdits → plan → auto. El modo actual aparece en la barra de estado.

Ten en cuenta que auto solo aparece en el ciclo si arrancaste la sesión con --enable-auto-mode. El modo bypassPermissions solo aparece si arrancaste con --permission-mode bypassPermissions o --dangerously-skip-permissions. Por su parte, dontAsk nunca aparece en el ciclo y debe activarse obligatoriamente al inicio.

Al iniciar: puedes especificar el modo directamente desde la línea de comandos:

• claude --permission-mode plan
• claude --permission-mode acceptEdits
• claude --permission-mode auto --enable-auto-mode
• claude --permission-mode bypassPermissions # Solo en entornos aislados
• claude --permission-mode dontAsk

Permisos de accesos

Los permisos de acceso en ./claude/settings.json de Claude Code sirven para controlar exactamente qué puede leer, modificar o ejecutar la IA dentro de tu proyecto. Este archivo define reglas granulares que determinan si Claude puede leer archivos, editar código, o ejecutar comandos Bash, y cada acción puede configurarse como permitida, preguntada o denegada. Las reglas se evalúan en orden estricto —deny → ask → allow— de modo que cualquier coincidencia en deny bloquea la acción sin importar lo demás, algo confirmado en la documentación oficial de Claude Code. Esto te permite proteger archivos sensibles como .env, carpetas de credenciales o comandos peligrosos como rm -rf, tal como recomiendan las guías de seguridad.

Además, settings.json permite definir modos de permisos que cambian el comportamiento global del agente: desde el modo default que pide permiso la primera vez que usa cada herramienta, hasta modos como plan (solo lectura), acceptEdits (acepta ediciones seguras automáticamente) o dontAsk (deniega todo lo no preaprobado) según la documentación oficial. También puedes usar patrones tipo gitignore para especificar rutas o comandos con comodines, como Edit:src/** o Bash:npm run *, lo que permite un control fino sobre qué partes del proyecto puede tocar Claude Code. En conjunto, este sistema convierte settings.json en la pieza central para equilibrar autonomía y seguridad en tu flujo de trabajo.

Permisos personalizados con Claude Code

Además de los modos, Claude Code tiene un sistema de reglas granulares que controla qué herramientas específicas puede usar. Las reglas se evalúan en orden de prioridad:

deny → ask → allow

La primera regla que coincida gana. Esto significa que deny siempre gana sobre allow, garantizando que las restricciones de seguridad nunca puedan ser anuladas por reglas más permisivas. Este orden se mantiene incluso en modos como bypassPermissions: las reglas deny se siguen aplicando aunque el resto de diálogos se omitan.

Sintaxis de reglas

Las reglas siguen el formato Herramienta o Herramienta(especificador).

Coincidencia total (sin paréntesis)

Cuando se indica únicamente el nombre de la herramienta, la regla captura todos sus usos:

• Bash → coincide con todos los comandos Bash
• Read → coincide con todas las lecturas de archivo
• Edit → coincide con todas las ediciones de archivo
• WebFetch → coincide con todas las peticiones web

Bash(*) es equivalente a Bash a secas.

Coincidencia específica (con especificador)

Añadiendo un especificador entre paréntesis se restringe la regla a usos concretos:

• Bash(uv run pytest) → solo el comando exacto uv run pytest
• Bash(uv run *) → cualquier comando que empiece con uv run
• Read(./.env) → leer el archivo .env del directorio actual
• WebFetch(domain:api.anthropic.com) → peticiones web a ese dominio
• mcp__puppeteer__puppeteer_navigate → una herramienta MCP específica
• Agent(Explore) → el subagente Explore

Patrones glob con *

Los wildcards pueden aparecer en cualquier posición del comando:

El espacio antes de * importa:

• Bash(ls *) coincide con ls -la pero no con lsof (exige espacio o fin de cadena tras ls)
• Bash(ls*) coincide con ambos, ls -la y lsof (sin límite de palabra)
• Bash(ls:*) es la sintaxis moderna equivalente a Bash(ls *)

Seguridad con operadores shell. Claude Code entiende operadores como &&, || o ;, así que una regla Bash(safe-cmd *) no permite ejecutar safe-cmd && evil-cmd: cada subcomando se evalúa por separado. Cuando apruebas un comando compuesto con "Sí, no volver a preguntar", Claude Code guarda una regla independiente por cada subcomando (hasta un máximo de 5), en lugar de una sola regla para toda la cadena.

Patrones para Read y Edit

Las reglas de Read y Edit siguen la especificación de .gitignore con cuatro tipos de ruta según el prefijo:

• //ruta → ruta absoluta desde la raíz del filesystem. Ej: Read(//etc/passwd)
• ~/ruta → ruta desde el home del usuario. Ej: Read(~/.ssh/*)
• /ruta → ruta relativa a la raíz del proyecto. Ej: Edit(/src/**/*.py)
• ruta o ./ruta → ruta relativa al directorio actual. Ej: Read(.env)

Conviene destacar un detalle contraintuitivo: /Users/alice/file no es una ruta absoluta, sino relativa a la raíz del proyecto. Para una ruta absoluta real hay que escribir //Users/alice/file. En Windows, las rutas se normalizan a formato POSIX antes de compararse (C:\Users\alice se convierte en /c/Users/alice), por lo que para cubrir archivos .env en toda una unidad se usaría //c/**/.env.

Ojo: en gitignore patterns, * coincide con archivos en un solo directorio, mientras que ** coincide recursivamente en todos los subdirectorios. Read(/src/*/*.py) coincide con src/pixelforge/processor.py pero no con src/pixelforge/filters/vignette.py. Para eso necesitas Read(/src/**/*.py).

Limitación importante de las reglas Read/Edit

Las reglas deny de Read y Edit aplican a las herramientas internas de Claude (Read, Grep, Glob), pero no a subprocesos de Bash:

• Una regla Read(./.env) bloquea la herramienta Read.
• Esa misma regla no previene cat .env en Bash.
• La documentación oficial señala además que Read se aplica "de mejor esfuerzo" incluso a herramientas nativas como Grep y Glob, así que no conviene tratarla como una barrera infalible.

Para enforcement a nivel de sistema operativo que bloquee todos los procesos, necesitas el sandbox (lo veremos mas adelante en el tema). El sandbox reutiliza las reglas deny de Read y Edit para el filesystem, y combina WebFetch(domain:...) con su propia lista allowedDomains para la red, cerrando el hueco que dejan las reglas por sí solas.

IA : Prompts : Claude : Copilot Permisos