El botón «hazlo tú»

Qué es y por qué importa

En el modo Manual, Claude Code te pide permiso antes de la mayoría de las acciones. Al principio lees cada pregunta. Al cabo de un rato pulsas sí sin leer, y a partir de ahí el permiso ya no te protege.

El botón «hazlo tú» es lo contrario: decides una sola vez, con la cabeza fría, qué puede hacer Claude solo y qué no. Libre dentro del proyecto: modificar archivos, lanzar los tests, arrancar el servidor. Bloqueado en tres cosas difíciles de deshacer: borrar, publicar, tocar la base de datos real.

Hacen falta dos piezas: un modo de permisos, que decide cuánto te pregunta Claude, y un archivo de reglas en el proyecto, que dice qué pasa siempre, qué pregunta siempre y qué está prohibido.

1. El modo

Yo trabajo en accept edits: Claude modifica los archivos del proyecto sin preguntar, y todo lo demás pasa por las reglas de abajo. También acepta solo algunos comandos básicos de archivos, como mkdir, mv, cp y rm, pero solo dentro de la carpeta del proyecto.

Para activarlo pulsa Shift+Tab hasta que debajo del prompt leas «accept edits on». En las versiones recientes la sesión arranca ya en auto mode, donde un segundo modelo revisa las acciones en tu lugar: el primer Shift+Tab te lleva a Manual, el segundo a accept edits. O lo eliges al arrancar, desde el terminal:

claude --permission-mode acceptEdits

Antes de darle un trabajo a Claude, mira siempre esa línea. Auto es cómodo y bloquea las acciones arriesgadas, pero la propia documentación dice que no garantiza la seguridad. Con accept edits sabes exactamente qué pasa solo, y las reglas valen en los dos.

2. Las reglas, una sola vez

Crea el archivo .claude/settings.json en la carpeta del proyecto. Si ya existe, no lo sobrescribas: añade la parte «permissions» a lo que ya hay. El mío es así:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run test *)",
      "Bash(npm run dev *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Bash(rm *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)",
      "Bash(npm publish *)",
      "Bash(vercel *)",
      "Bash(npx vercel *)",
      "Bash(supabase db push *)",
      "Bash(psql *)",
      "Read(./.env.production)"
    ]
  }
}

Pon tus comandos en lugar de los míos (los tests, el servidor, el despliegue, el cliente de tu base de datos real). Ojo: en accept edits también rm dentro del proyecto pasaría solo, por eso está en los deny.

Qué hace cada parte

• defaultMode: el modo con el que arranca la sesión en el terminal. Arrancas en accept edits aunque el predeterminado fuera auto. El flag --permission-mode gana al archivo.
• allow: los comandos que Claude lanza sin preguntar: tests, lint, servidor de desarrollo. Bash(npm test *) cubre npm test solo y con cualquier opción detrás.
• ask: los comandos sobre los que quieres una pregunta cada vez, en cualquier modo, también en auto. git push manda el código a internet: lo quiero ver antes.
• deny: lo que no debe pasar nunca: borrar archivos, el push forzado, publicar, el despliegue, la base de datos real. vercel y npx vercel son dos líneas porque la regla sobre vercel no ve el comando con npx delante.
• Read(./.env.production): Claude no lee el archivo con las claves de producción, ni con sus herramientas ni con cat, y no puede modificarlo.

No tienes que escribir el archivo a mano. Puedes pedirle a Claude que lo adapte:

Lee el package.json y los scripts de este proyecto. Luego adapta este archivo .claude/settings.json: en allow pon los comandos reales de los tests, del lint y del servidor de desarrollo; en deny, los comandos que borran archivos, publican la app, hacen el despliegue o tocan la base de datos de producción. No pongas en allow nada que borre o mande algo a internet. Enséñame el archivo antes de guardarlo.

[pega aquí el archivo]

Cuando Claude guarda el archivo te pide permiso también en accept edits: es normal, la carpeta .claude está protegida.

3. Tres cosas que debes saber

El deny gana siempre

Claude Code revisa las reglas en este orden: primero deny, luego ask, luego allow. Decide la primera que coincide. Un allow no abre un agujero en un deny, ni siquiera si es más preciso. Y los deny valen en cualquier modo.

En mi archivo: git push --force está tanto en el ask como en el deny, y gana el deny. En cambio, git push origin main --force el deny no lo ve, porque no empieza por «git push --force». Eso sí, empieza por «git push», y el ask te hace la pregunta. Por eso mantengo las dos líneas.

Las reglas leen el texto del comando

Las reglas leen el texto del comando: bash -c 'rm -rf build' o /bin/rm se cuelan por debajo de «Bash(rm *)». La regla no los reconoce, y entonces deciden el modo y las demás reglas.

Para una guardia de verdad usa un hook PreToolUse (el guardián del TIPS 05) o la sandbox (/sandbox). El hook lee todo el texto de cada comando antes de que se ejecute, también dentro de bash -c. Con la sandbox es el sistema operativo el que limita qué escriben los comandos fuera del proyecto y a qué webs se conectan. Pero dentro del proyecto deja escribir: un rm ahí solo lo para el hook.

El modo sin controles

El modo sin ningún control (--dangerously-skip-permissions) úsalo solo dentro de un contenedor o una máquina virtual, nunca en el ordenador con tus archivos. También la documentación lo recomienda solo en entornos aislados. Si en tu ordenador quieres menos preguntas, el camino es accept edits con las reglas, o auto.

4. Comprueba

Escribe /permissions dentro de Claude Code: ves todas las reglas activas y de qué archivo viene cada una. Si falta una regla, normalmente el archivo está en el sitio equivocado o el JSON tiene un error, como una coma que falta.

Luego haz una prueba de verdad. Escríbele a Claude:

Crea un archivo vacío llamado prueba-permisos.txt. Luego prueba estos tres comandos, uno a uno, y para cada uno dime qué ha pasado: bloqueado por una regla, me has pedido permiso, o se ha ejecutado solo.
- npm test (o el comando de los tests de este proyecto)
- rm prueba-permisos.txt
- git push --dry-run
Si un comando se bloquea, no busques otras formas de lanzarlo.

Lo que esperas es esto: tests ejecutados solos, rm bloqueado, git push con pregunta (con --dry-run no manda nada a internet). El archivo de prueba lo borras tú después: Claude no puede.

Errores comunes

• Copiar el archivo sin cambiar los comandos: si tus tests no se lanzan con npm test, el allow no sirve y Claude te pregunta cada vez. Pon los comandos reales de tu proyecto.
• Trabajar en accept edits sin rm en los deny: dentro del proyecto rm pasa solo. Déjalo en los deny y los archivos que sobran bórralos tú.
• Creer que el deny cubre cualquier forma del comando: bash -c o /bin/rm pasan. Para una guardia de verdad, añade el hook o la sandbox.
• Fiarse de las instrucciones en el chat, tipo «no borres nada»: orientan a Claude pero no bloquean nada. Lo que no debe pasar nunca va en los deny.
• No mirar en qué modo estás: la sesión puede arrancar en auto sin que lo hayas elegido. Antes de un trabajo largo, lee la línea debajo del prompt.

Lista de comprobación

• Modo elegido y comprobado debajo del prompt
• .claude/settings.json con los comandos de tu proyecto
• rm, despliegue, publish y base de datos real en los deny
• git push en el ask
• Reglas comprobadas con /permissions
• Prueba hecha: tests libres, rm bloqueado, push con pregunta
• Nada de --dangerously-skip-permissions en tu ordenador

Preguntas frecuentes