Claude Code pide permiso para todo: cómo cortarlo sin perder el control

Claude Code te pide permiso antes de cada edición y de cada comando. Los primeros diez minutos lo agradeces. A partir de ahí apruebas por reflejo, y aprobar sin leer es lo mismo que no revisar: te quedas con la fricción y pierdes el control.

La salida habitual es el otro extremo. Un alias con --dangerously-skip-permissions y a trabajar en tu máquina principal. Funciona hasta el día que deja de funcionar.

Entre los dos extremos hay cinco palancas para que Claude Code deje de pedir permiso para todo. No son alternativas, se suman, y conviene usarlas en orden: primero las que quitan prompts sin quitar ninguna protección, al final las que quitan protecciones. Esta guía las ordena y te lleva al tip que explica cada una a fondo. La escribo desde el uso diario: paso muchas horas al día en Claude Code y cambié del modo YOLO a auto mode el día que salió.

Por qué te pregunta tanto

Cada llamada a una herramienta pasa por la capa de permisos antes de ejecutarse. Ahí se evalúan tus reglas en un orden fijo: primero deny, luego ask, luego allow, y gana la primera que casa. La sintaxis Tool(specifier) admite wildcards y patrones de gitignore, así que una sola regla como Bash(npm run *) cubre una familia entera de comandos. Los tres conceptos están en permisos en Claude Code: reglas deny, modos y wildcards.

Lo que no cubre ninguna regla lo decide el modo. En default Claude lee libremente y pregunta antes de cada edición y cada comando. acceptEdits aprueba ediciones y los comandos básicos del sistema de archivos, pero npm test, git push o curl siguen preguntando, y esa confusión explica buena parte de la fatiga. Qué aprueba cada uno de los seis está en los 6 modos de permisos.

Y la regla tiene que vivir en el archivo correcto. Un "no hagas push" escrito en CLAUDE.md es una sugerencia; la misma regla en permissions.deny de settings.json la aplica el motor, decida Claude lo que decida. Las del equipo se commitean en .claude/settings.json, las tuyas van en settings.local.json, que Claude Code deja fuera de git al crearlo: CLAUDE.md, settings.json o .mcp.json.

Con eso claro, el orden.

1. Convierte lo que se repite en reglas

La mayoría de tus prompts son los mismos diez comandos de solo lectura. Antes de tocar el modo, conviértelos en reglas allow. El riesgo es casi nulo: solo apruebas de antemano lo que ya aprobabas a mano.

No hace falta escribirlas. /fewer-permission-prompts lee tus últimas 50 sesiones, se queda con los comandos read-only que aprobaste al menos tres veces y propone hasta 20 reglas para el .claude/settings.json del proyecto. Descarta los wildcards peligrosos, como Bash(python3:*), y los comandos que escriben. Allowlist automática en Claude Code.

Si el prompt sale siempre dentro de la misma skill, el campo allowed-tools de su frontmatter aprueba solo las herramientas que listas mientras la skill está activa; lo demás sigue preguntando. Ejecútala dos o tres veces, apunta lo que apruebas y escríbelo ahí. allowed-tools en tus skills.

En claude -p no hay nadie para pulsar, así que la regla se declara al arrancar: --allowedTools "Read" "Bash(curl *)" dice exactamente qué puede hacer el agente, y para una auditoría de solo lectura basta con "Read" "Glob" "Grep". Claude Code puede trabajar mientras duermes.

2. Elige el modo según la tarea

El modo no se decide una vez. Es un dial que mueves con Shift+Tab según lo que vas a hacer.

Para una tarea que todavía no entiendes, plan mode: Claude investiga y propone sin tocar un archivo, y al aprobar eliges si sigue en auto mode o aprobando tú cada edición. Ctrl+G abre el plan en tu editor antes de aprobarlo. Plan mode no hace más inteligente a Claude, te obliga a entender tú.

Si lanzas un plan y te levantas, el "¿procedo con el plan?" se queda esperando. Un hook PermissionRequest con "matcher": "ExitPlanMode" responde solo a esa pregunta; Bash, edits y MCP siguen preguntando igual. Deja de aprobar cada plan en Claude Code.

La misma sintaxis Tool(patrón) filtra hooks: el campo if evita que el hook llegue a lanzarse cuando la llamada no casa. Es una herramienta de rendimiento, no de seguridad. Un allow o un deny que tiene que cumplirse se declara en las reglas de permisos, no en un hook. Hooks condicionales, y el resto de eventos en la guía práctica de hooks.

3. Deja que apruebe un clasificador: auto mode

Este es el salto grande. Auto mode pone un clasificador entre Claude y tu máquina: lo seguro se ejecuta sin preguntar y lo arriesgado (curl | bash, deploys a producción, force push) se bloquea. Casi toda la fluidez de YOLO, con red. Olvídate de los permisos en Claude Code sin caer en modo YOLO.

Dos detalles de configuración antes de fiarte. Desde la v2.1.228 las sesiones nuevas arrancan en auto en Pro, Max y Team, pero si quieres fijarlo, "defaultMode": "auto" tiene que ir en ~/.claude/settings.json: en el .claude/settings.json del proyecto se ignora sin avisar. Y si ese archivo del proyecto todavía tiene "defaultMode": "bypassPermissions", la sesión arranca en Manual aunque tus ajustes de usuario digan auto: bypass permissions en Claude Code: tu proyecto ya no puede activarlo. Las reglas allow amplias, como Bash(*), también se desactivan mientras auto está activo; las estrechas del paso 1 se mantienen.

El clasificador lee prosa, no patrones, así que puedes darle reglas tuyas en una frase con autoMode.soft_deny en ~/.claude/settings.json. Pon "$defaults" como primer elemento: sin él, tu frase sustituye a todas las reglas de fábrica. Lo compruebas con claude auto-mode config. Escribe tus propias reglas de auto mode.

Las reglas de fábrica también crecen. Ya frena el git destructivo en local (git reset --hard, git clean -fd), un rm -rf sobre una variable que no puede resolver y las escrituras al transcript de la sesión, y los permite en cuanto tu intención es explícita. Cuando algo se bloquea, el motivo está en la pestaña "Recently denied" de /permissions. Ahora auto mode te protege de ti mismo.

Un coste a tener en cuenta: entrar o salir de auto mode rompe la caché de prompt, así que conviene elegirlo al empezar la sesión y no alternar: prompt caching en Claude Code.

4. Levanta una valla: /sandbox

Auto mode decide con un modelo. /sandbox no decide nada: con la opción de auto-allow, los comandos se ejecutan sin preguntar, pero el sistema operativo impide escribir fuera del proyecto o llamar a dominios que no autorizaste. Cuidado con las lecturas: por defecto llega a ~/.ssh y ~/.aws/credentials hasta que las bloqueas con sandbox.filesystem.denyRead. Funciona en macOS, Linux y WSL2, y se complementa con auto mode: el clasificador decide qué intenta Claude, la valla limita hasta dónde llega. /sandbox en Claude Code.

5. Bypass, solo dentro de un contenedor

--dangerously-skip-permissions (el modo bypassPermissions) quita el clasificador y casi todas las barreras (las reglas deny siguen bloqueando). Tiene su sitio: contenedores efímeros, VMs, CI aislado. En tu máquina principal, no.

En CI tiene además una trampa propia. En claude -p, un permiso denegado no rompe la ejecución: devuelve exit 0, "subtype": "success" y "is_error": false aunque Claude no haya tocado un fichero, y la única huella está en permission_denials. Por eso tanta gente acaba pegando el flag en el pipeline, cuando el orden correcto es --allowedTools, luego --permission-mode dontAsk, luego auto, y bypass al final. Por qué tu script acaba en verde sin haber hecho nada.

Si trabajas con varias sesiones, bypass tiene otro efecto: una sesión en bypassPermissions retiene los mensajes que le manda una sesión que sí pregunta, hasta que los apruebas a mano. Y un mensaje de otra sesión nunca cuenta como tu consentimiento. Mensajes entre sesiones de Claude Code.

Los permisos llegan más allá del terminal

El modo que elijas también gobierna el navegador. Con /chrome, Claude trabaja en tu Chrome con tus sesiones iniciadas: en Auto el clasificador aprueba las acciones rutinarias, y en Don't Ask lo que necesitaría aprobación se salta sin avisarte, así que la tarea sigue sin ese clic. /chrome en Claude Code.

Y cuando te levantas de la mesa, un solo prompt detiene la tarea entera. Push when actions required te avisa en el móvil cuando Claude te espera. Si el aviso salta demasiado, el problema no es la notificación, son los permisos: vuelve a los pasos 1 y 3. Notificaciones de Claude Code en el móvil.

Qué hacer hoy

1. Ejecuta /fewer-permission-prompts y revisa las reglas que propone antes de aceptarlas.
2. Fija "defaultMode": "auto" en ~/.claude/settings.json, quita cualquier bypassPermissions del .claude/settings.json del proyecto y añade una regla tuya en autoMode.soft_deny, con "$defaults" delante.
3. Activa /sandbox con auto-allow y bloquea la lectura de ~/.ssh y ~/.aws.
4. Deja --dangerously-skip-permissions para los contenedores, y en claude -p lee permission_denials.

Con eso, los prompts que te sigan saliendo son pocos y merecen que los leas. Ese es el control que buscabas.

Si estás empezando, el contexto de todo esto está en primeros pasos con Claude Code, que trata los permisos junto a sesiones, contexto, cuota y modelos.