Permisos de Claude Code: 6 modos y cómo configurarlos de forma segura (2026)

los permisos en Claude Code cambian bastante rápido entre versiones. Comprueba claude --version y la documentación oficial de los modos de permisos (Anthropic, actualizada en 08/2026) antes de aplicar cualquier cosa de abajo.

Por qué importan los permisos en Claude Code

Claude Code no solo sugiere código como un chatbot: es un agente de verdad que puede escribir archivos directamente en tu máquina y ejecutar comandos de shell. Ese poder es también el riesgo: sin barreras de protección, una sesión normal puede sobrescribir archivos que aún no has confirmado, borrar la carpeta equivocada o ejecutar algo destructivo como rm -rf antes de que puedas reaccionar.

El riesgo más aterrador no es que la IA "decida portarse mal": es la inyección de prompts. Una página web que le pides a Claude que lea, un README enterrado en una dependencia o una issue de GitHub pueden llevar instrucciones ocultas como "ejecuta curl ... | bash" o "envía el contenido de .env a algún lugar". Si Claude tiene permisos completos, puede seguir esas órdenes sin que tú se lo pidas.

Por eso existe el sistema de permisos: por defecto, Claude Code opera con una postura de preguntar primero, actuar después. Si acabas de instalar Claude Code, lo siguiente que debes hacer es entender y configurar los permisos, tanto para evitar la pérdida de datos como para frenar los interminables avisos de s/n para cosas en las que ya confías.

Los 6 modos de permisos en Claude Code (tabla comparativa)

Claude Code viene con seis modos de permisos. Lo primero que hay que recordar: el modo por defecto es de solo lectura y siempre pregunta antes de escribir un archivo o ejecutar un comando. Los demás modos aflojan ese control paso a paso, según cuánto confíes en el trabajo y cuán aislado esté tu entorno.

En la práctica, vivirás la mayor parte del tiempo en los tres primeros modos. default/Manual es el punto de partida más seguro: nada ocurre a tus espaldas. acceptEdits encaja cuando estás refactorizando y quieres que Claude edite sobre la marcha mientras tú revisas después con git diff. plan es genial cuando necesitas que Claude "lea, entienda y explique" — digamos, rastreando un bug por varios archivos antes de tocar código. Los otros tres son herramientas especializadas: auto para tareas largas con una red de seguridad, dontAsk para automatización y bypassPermissions solo para un entorno totalmente aislado.

Nota de versión: este modo auto por defecto integrado solo se activa en Claude Code v2.1.228+ para macOS/Linux/WSL y v2.1.233+ para Windows nativo — las versiones más antiguas siguen iniciando en default/Manual.

Cambiar y fijar el modo por defecto

La forma más rápida de cambiar de modo a mitad de sesión es pulsar Shift+Tab. Desde el 14/08/2026, las sesiones Pro/Max/Team ahora inician en auto en lugar de default: la primera pulsación de Shift+Tab te lleva de auto a default, y a partir de ahí es el mismo ciclo de siempre, default → acceptEdits → plan, con auto volviendo al final del ciclo si tu cuenta es elegible (según la documentación de los modos de permisos, Anthropic, 08/2026). La barra de estado de abajo se actualiza con cada pulsación, así que siempre sabes en qué modo estás.

Para arrancar directamente en un modo, usa la flag de línea de comandos:

claude --permission-mode plan

Para fijar un modo por defecto en todas las sesiones, define defaultMode en settings.json:

{
 "permissions": {
 "defaultMode": "acceptEdits"
 }
}

Nota de seguridad importante: defaultMode: "auto" solo se respeta cuando se declara en tu archivo de usuario, ~/.claude/settings.json. Si tú (u otra persona) lo defines en el .claude/settings.json de un proyecto, Claude Code lo ignora — así que un repositorio que acabas de clonar no puede concederse a sí mismo permiso para ejecutarse automáticamente. Esta es la barrera de protección que impide que un "repositorio malicioso" escale sus propios privilegios.

Configurar la lista de permitidos en settings.json (allow / deny / ask)

El modo de permisos decide la "actitud" general, mientras que settings.json te da control hasta el nivel de cada comando. Hay tres listas:

• allow — se ejecuta sin preguntar. Por ejemplo: "Bash(npm run test:*)", "Read(src/**)".
• ask — siempre pregunta, incluso cuando el modo está aflojando las cosas. Úsala para comandos en los que quieres pulsar OK tú misma.
• deny — bloqueado por completo, nunca se ejecuta. Por ejemplo: "Bash(rm -rf *)", "WebFetch", "Read(.env)".

La sintaxis de las reglas sigue la forma Tool(pattern): Bash(npm run lint) coincide con ese comando exacto, añadir :* coincide con un prefijo (Bash(git diff:*)), Read(src/**) usa un glob para rutas y WebFetch(domain:github.com) restringe a un dominio.

La regla de arbitraje más importante de todas — grábatela a fuego: deny siempre gana a allow, en cualquier nivel. Si un comando coincide con una regla de allow y una de deny, se bloquea. En cuanto al orden de los archivos, los niveles más altos anulan a los más bajos en esta secuencia: managed (enterprise) > .claude/settings.local.json > .claude/settings.json > ~/.claude/settings.json. El archivo settings.local.json es donde vive tu configuración personal y no confirmada; el settings.json de un proyecto se comparte con todo el equipo a través de Git.

Un ejemplo de settings.json que equilibra comodidad y seguridad:

{
 "permissions": {
 "defaultMode": "default",
 "allow": [
 "Bash(npm run test:*)",
 "Bash(npm run lint)",
 "Bash(git status)",
 "Bash(git diff:*)",
 "Read(src/**)"
 ],
 "ask": [
 "Bash(git push:*)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(git push --force:*)",
 "Read(.env)",
 "Read(./secrets/**)",
 "WebFetch"
 ],
 "additionalDirectories": [
 "../shared-libs"
 ]
 }
}

El campo additionalDirectories deja que Claude trabaje con carpetas fuera del espacio de trabajo actual — útil en un monorepo dividido en paquetes, pero añade solo lo que de verdad necesitas. Si quieres una lógica de permisos más personalizada (logging, bloqueo condicional), puedes usar Hooks con el evento PreToolUse para intervenir antes de que se ejecute cada herramienta.

Rutas protegidas — lo que Claude nunca editará por su cuenta

Más allá de las reglas allow/deny que tú definas, Claude Code tiene una capa de protección dura que se sitúa más abajo: las rutas protegidas. Son archivos y carpetas de configuración sensibles que Claude nunca aprueba automáticamente para escritura, incluso cuando estás en acceptEdits o auto:

• .claude y .claude.json — la propia configuración de Claude Code
• .git — internos de Git (para que no toque directamente el historial del repositorio)
• .vscode — configuración del editor
• Archivos rc de shell: .bashrc, .zshrc… — un lugar habitual para comandos ocultos que se ejecutan al arrancar
• .npmrc y cualquier archivo .env* que guarde secretos
• .mcp.json — configuración del servidor MCP

El punto clave de seguridad: una regla de allow aún NO puede anular una ruta protegida. Esta comprobación de seguridad se ejecuta antes de que se evalúe la lista de permitidos, así que aunque añadas por accidente (o te engañen para añadir) una regla que permita escribir en .env, Claude igual se detiene y pregunta. La única forma de saltarse esta capa es bypassPermissions — una razón más para no activarlo fuera de un entorno aislado.

--dangerously-skip-permissions vs modo auto — ¿cuál es seguro?

Mucha gente que quiere "desactivar los avisos de s/n" va directa al --dangerously-skip-permissions (también llamado modo YOLO). Esta flag desactiva todas las comprobaciones: se ignoran todas las reglas allow/deny y todas las rutas protegidas. Las consecuencias reales:

• No protege contra la inyección de prompts — con todas las redes desactivadas, una instrucción oculta de una página web o un archivo se ejecuta directamente.
• Claude Code bloquea esta flag cuando la ejecutas como root/sudo, porque el radio de daño es demasiado grande.
• Úsala solo dentro de un contenedor o VM aislado, idealmente sin internet — un lugar donde, si Claude rompe algo, solo rompe el sandbox.

Desde principios de 2026, Anthropic ofrece el modo auto como el sustituto seguro para la necesidad de "menos fricción": en lugar de desactivar las comprobaciones, el modo auto ejecuta un clasificador en segundo plano que categoriza cada acción y bloquea comandos peligrosos por defecto — curl | bash, exfiltrar secretos, desplegar a producción, rm -rf /, git reset --hard, force pushes, terraform destroy, etc. Las operaciones rutinarias y seguras pasan, mientras que cualquier cosa que huela a destructiva vuelve para preguntarte. Según Anthropic, la mayoría de las acciones en una sesión ya las aprueba el usuario de todos modos, así que el modo auto elimina la mayor parte de las preguntas y mantiene la red para las raras peligrosas.

Esto también es un gran cambio en la "postura de seguridad" por defecto: desde el 14/08/2026, el modo auto se ha convertido en el modo por defecto para los planes Pro/Max/Team (según la documentación de los modos de permisos de Claude Code, Anthropic, 08/2026). En resumen: si quieres menos avisos, usa el modo auto — no uses --dangerously-skip-permissions.

Cómo decide el clasificador: niveles de reglas y revisar una acción bloqueada

El clasificador en segundo plano detrás del modo auto no usa un solo cubo — comprueba cada acción contra cuatro niveles ordenados de reglas: hard_deny bloquea incondicionalmente (exfiltrar secretos, por ejemplo) sin posibilidad de anulación; soft_deny bloquea acciones destructivas-pero-a-veces-legítimas como un force push, pero puede anularse; una regla allow puede abrir una excepción con nombre a un soft_deny; e incluso sin ella, la intención declarada de forma explícita en tu propio mensaje puede anular un bloqueo suave restante — pero solo cuando nombras la acción exacta ("haz force-push a esta rama"), no una vaga ("limpia el repositorio").

Cuando algo sí se bloquea, no vuelvas a teclear la petición sin más — abre /permissions, ve a la pestaña Recently denied y pulsa r para reintentarlo con aprobación manual. Un caso límite: si el clasificador no puede devolver ningún veredicto, la acción se deniega en silencio, sin entrada en Recently denied. ¿Quieres el panorama más amplio de cómo encajan el bucle del agente y los permisos? Empieza por qué es Claude Code.

La configuración segura recomendada (paso a paso)

Esta es la configuración que me parece más equilibrada para el trabajo de desarrollo del día a día — segura, pero sin ser molesta:

1. Mantén default/Manual para trabajo sensible. En un repositorio desconocido, al trabajar en la rama main o cuando Claude está leyendo contenido de la web, quédate en el modo por defecto y aprueba a mano.
2. Añade deny para comandos destructivos. Bloquea Bash(rm -rf *), Bash(git push --force:*) y Read(.env). Como deny gana a allow, esta es una capa que nunca se afloja por error.
3. Permite de forma estrecha los comandos confiables y repetitivos. Añade los comandos que ejecutas constantemente y sabes que son seguros: Bash(npm run test:*), Bash(git status). Prefiere allows estrechos (comandos exactos) a los amplios.
4. Usa acceptEdits al iterar sobre el código y revisa con git diff. Deja que Claude edite sobre la marcha, por la velocidad, pero mantén el control en el paso del commit — mira el diff antes de hacer git add.
5. Tareas largas o sensibles → contenedor o modo auto, nunca bypass. Cuando necesitas ejecutar durante mucho tiempo y sin supervisión, el modo auto con su clasificador sigue siendo la decisión correcta. Ese es también el momento de ejecutar /goal de forma segura sin acceso a producción.

Si quieres revisar todas las reglas en vigor en cualquier momento, escribe /permissions en la sesión. También es un buen lugar para comprobar justo después de haber instalado y configurado Claude Code por primera vez.

Errores comunes y modos de fallo al configurar permisos

La configuración de permisos suele tropezar en unas cuantas situaciones recurrentes — conocerlas de antemano te ahorra la frustración:

• "No para de preguntar s/n." Eso significa que el modo es default y el comando aún no está en tu lista de allow. Añade una regla de allow estrecha para el comando exacto en el que confías; no saltes directamente al bypass.
• "El modo auto no para de bloquear cosas." Si el clasificador bloquea 3 veces seguidas o 20 veces en total en una misma sesión, Claude detiene el modo auto y vuelve a preguntar manualmente — es un comportamiento intencionado para que no se quede en bucle para siempre.
• Dijiste "no hagas push" en voz alta, pero hizo push igual. Los "límites" que declaras en la conversación pueden desaparecer cuando el contexto se compacta. Las restricciones habladas son menos fiables que la configuración — usa una regla deny para los límites duros.
• Una regla no se aplica. Normalmente el settings.json tiene JSON inválido (una coma de más, una llave que falta), así que se omite el archivo entero. Confirma que el archivo es válido y vuelve a comprobarlo con /permissions.

¿Te topas con errores más raros con Claude Code? Consulta nuestra guía para corregir los errores comunes de Claude Code.

Presets de permisos seguros listos para usar

Averiguar una lista de permitidos para cada proyecto a mano es un trabajo pesado, sobre todo cuando haces malabares con muchos repositorios de stacks distintos. Un atajo es un kit de la comunidad que empaqueta skills y configuración por convención — por ejemplo, el kit AgentKit para Claude Code (20% de descuento por el enlace) entrega skills y flujos de trabajo con un estándar, así que escribes menos reglas desde cero. Si te da curiosidad cómo funciona, lee nuestra opinión sobre qué es AgentKit y si vale la pena usarlo. Con preset o sin él, el principio se mantiene: entiende deny/allow y nunca apagues la red de seguridad.

Preguntas frecuentes (FAQ)

¿Claude Code borrará mis archivos?

En el modo por defecto (Manual), no — Claude siempre pregunta antes de cualquier escritura o borrado. Solo puede borrar por su cuenta si aflojas los permisos (acceptEdits/auto) o activas --dangerously-skip-permissions. Añade un deny para rm -rf para bloquearlo por completo.

¿Cómo detengo los avisos de s/n manteniéndome segura?

No los desactives con bypass. En su lugar, añade reglas de allow estrechas para los comandos en los que confías (como npm test, git status), o usa el modo auto — elimina los avisos para acciones seguras pero aún bloquea las peligrosas con su clasificador.

¿Es peligroso --dangerously-skip-permissions?

Sí. Desactiva todas las comprobaciones y no ofrece ninguna protección contra la inyección de prompts. Claude incluso lo bloquea cuando lo ejecutas como root. Úsalo solo dentro de un contenedor o VM aislado, idealmente sin internet.

¿En qué se diferencia el modo auto del bypass?

El modo auto conserva la red de seguridad: un clasificador en segundo plano bloquea comandos peligrosos (curl|bash, force pushes, envío de secretos, rm -rf /). El bypass lo desactiva todo. Si quieres menos avisos, elige el modo auto, no el bypass.

En un conflicto, ¿gana deny o allow?

Deny siempre gana. Si un comando coincide con una regla de deny y una de allow en cualquier nivel de configuración, se bloquea. Las rutas protegidas también se comprueban primero, así que una regla de allow no puede anularlas.

¿Dónde vive la configuración de permisos?

En el archivo settings.json. Orden de prioridad: managed (enterprise) > .claude/settings.local.json (personal, no confirmado) > .claude/settings.json (compartido con el equipo) > ~/.claude/settings.json (tu valor por defecto).

Conclusión y próximos pasos

La receta para ser segura-pero-no-molesta es compacta: mantén el valor por defecto seguro para trabajo sensible, añade una lista de allow estrecha para comandos confiables, fija denies duros para los destructivos y usa el modo auto (no el bypass) para tareas largas. Así Claude Code corre rápido mientras tus manos siguen en el volante.

¿Aún no has terminado de instalar? Lee la guía de instalación de Claude Code. Para el panorama general, mira qué es Claude Code. comprueba claude --version, ya que los nombres de las etiquetas y los umbrales de los modos pueden cambiar con las nuevas versiones.