Guías prácticas para trabajar con agentes de IA
Lo que Claude puede hacer en tu máquina no lo decide lo que escribas en CLAUDE.md, sino las reglas de permisos, que se miran siempre en el mismo orden: deny, ask, allow. Aquí ves ese orden, lo que una regla de Bash no llega a ver y en qué caso un mod instalado puede aprobar lo que tú habías negado.
8 min de lectura laboratorio: lista de comprobación publicado el 24 oct 2026
Quieres que el agente —el programa que recibe un objetivo y decide él los pasos— no lea tu fichero de secretos, no suba nada a la rama principal y no borre carpetas. Lo habitual es escribirlo en CLAUDE.md, el fichero de instrucciones que Claude Code lee al abrir cada sesión, o meter el fichero en un .claudeignore por analogía con .gitignore.
Ninguna de las dos cosas le quita a Claude la posibilidad de hacerlo. Lo que se permite y lo que no lo decide el propio Claude Code, no el modelo: lo que escribas en CLAUDE.md orienta lo que Claude intenta, pero no cambia lo que el programa le deja hacer. V Y un .claudeignore no tiene ningún efecto. V
Lo que sí lo decide son las reglas de permisos, y se evalúan en un orden fijo que casi nadie conoce entero. Esta guía cuenta ese orden, lo que una regla no llega a ver y quién puede pasar por encima de ella.
Una regla de permisos es una línea en un fichero de ajustes que dice qué hace Claude Code cuando Claude quiere usar una herramienta concreta. Hay tres clases, y cada una hace una cosa: allow la deja correr sin preguntarte, ask te pregunta siempre y deny la impide. V
Se escriben con el nombre de la herramienta y, si hace falta, un patrón entre paréntesis: Bash(npm run build) casa con esa orden exacta, Read(./.env) con leer el .env de la carpeta actual y WebFetch(domain:example.com) con las descargas de ese dominio. V El asterisco hace de comodín: Bash(git push *) casa con cualquier git push que lleve algo detrás.
Sin ninguna regla tuya, Claude Code ya pregunta por defecto antes de casi todo lo que cambia algo. Leer ficheros dentro de la carpeta de trabajo no pide permiso. Ejecutar una orden de shell sí, salvo una lista fija de órdenes de solo lectura. Editar ficheros, también. V
Para ver qué reglas tienes, la orden es /permissions dentro de una sesión: enseña todas, cada una con el fichero de ajustes del que sale. V Y cuando contestas «sí, y no vuelvas a preguntar» a una orden de shell, la regla se guarda en .claude/settings.local.json, en la raíz del repositorio, y vale desde entonces para cualquier sesión en ese repositorio. V Conviene mirar ese fichero de vez en cuando: es donde se acumula lo que fuiste aprobando con prisa.
Las reglas se miran en este orden: primero deny, luego ask, luego allow. La primera que coincide decide, y que una regla sea más concreta que otra no cambia ese orden. V
Lo que esto quiere decir en la práctica es que un allow no puede abrir una excepción dentro de un deny. Si niegas Bash(aws *) para que no toque tu nube y permites Bash(aws s3 ls) para que pueda listar, el listado también queda bloqueado: la regla ancha de deny se mira antes y gana. V Lo mismo pasa entre ask y allow: un ask que case te pregunta aunque haya un allow más concreto para esa misma llamada. V Si quieres la excepción, el deny tiene que ser más estrecho, no el allow.
El orden aguanta también entre ficheros. Si tus ajustes de usuario permiten algo y los del proyecto lo niegan, gana el deny, y al revés igual: un deny en cualquier nivel no lo levanta un allow de otro. V Y por encima de todo están los ajustes gestionados, los que pone una organización en la máquina: ningún otro nivel, ni siquiera una opción en la línea de órdenes, puede saltarse un permiso gestionado. V
Queda una diferencia que conviene conocer. Negar la herramienta entera, con Bash a secas, la quita del contexto —lo que el modelo tiene delante en cada petición— y Claude ni siquiera sabe que existe. Negar un patrón, como Bash(rm *), deja la herramienta visible y bloquea solo las llamadas que casan cuando Claude las intenta. V
Una regla de Bash casa con el texto de la orden que escribe Claude, después de que Claude Code la parta por los operadores (&&, ;, |…) y le quite algunos envoltorios conocidos, como timeout o nohup. V No casa con el mismo programa llamado de otra forma. La documentación lo dice así: una regla deny o ask cubre la forma en que Claude suele escribir la orden, y no es una frontera de seguridad alrededor del programa. V
Los ejemplos son de la propia documentación: Bash(rm *) en deny para rm -rf build/, pero no /bin/rm -rf build/ ni bash -c 'rm -rf build/'; Bash(git push *) para git push origin main, pero no git -C . push origin main. V
Hay también un riesgo del lado del allow. Los programas que ejecutan lo que les pasas detrás, como npx, docker exec o devbox run, no están en la lista de envoltorios que se quitan, así que Bash(devbox run *) permite cualquier cosa que venga después, incluido devbox run rm -rf .. La salida es escribir una regla por cada orden concreta, como Bash(devbox run npm test). V
La propia comprobación tiene fallos que se van arreglando. La versión 2.1.309, del 22 de octubre, corrigió tres: una regla deny de Edit(ruta) no paraba en algunas órdenes una redirección de Bash a esa ruta cuando la orden llevaba también una subshell; la comprobación se fiaba de una variable puesta por una orden cuya redirección podía fallar; y algunas órdenes compuestas que cambian de carpeta antes de llamar a git no pedían permiso. V Están cerrados con esa versión. Los contamos porque enseñan la clase de fallo: una comprobación que lee texto siempre va un paso por detrás de lo que el texto puede hacer.
Lo que no depende del texto de la orden es el sandbox, el entorno aislado que el sistema operativo impone a las órdenes de shell y a todo lo que lancen. La documentación recomienda usar los dos a la vez, porque las restricciones del sandbox siguen valiendo aunque una inyección de instrucciones —texto escondido en algo que el agente lee y que intenta darle órdenes— consiga torcer lo que Claude decide. V
Un hook PreToolUse es un programa tuyo que Claude Code ejecuta antes de cada herramienta, y que puede bloquear la llamada, forzar la pregunta o dejarla pasar sin preguntar. V Encaja con las reglas así:
Esto permite un montaje que la documentación sugiere: permitir Bash entero para no recibir preguntas y poner un hook que rechace las órdenes concretas que no quieres. V El hook ve el texto completo de la orden y puede aplicar la lógica que tú escribas; sigue siendo texto, con los mismos límites del apartado anterior.
El caso que cambia la última palabra: los mods. Un mod es una extensión que instalas en Claude Code y que puede contestar a la comprobación de permisos. Contesta después de las reglas y de los hooks. V Si en la máquina hay ajustes gestionados, o si la sesión ha entrado con un /login de Team o Enterprise, lo que bloqueó un deny o un hook sigue bloqueado aunque el mod lo apruebe, y lo que pedía pregunta sigue preguntando. V Sin ninguna de las dos cosas, el mod puede aprobar una llamada que una regla deny rechaza o que un hook bloqueó. V Una sesión que corre con una clave de API o con una credencial de larga duración (CLAUDE_CODE_OAUTH_TOKEN) no cuenta como ese login, aunque lo tengas guardado. V
Quien trabaja con Pro o Max en su propio ordenador está en el segundo caso. Antes de dar por hecho que un deny te protege, mira qué mods tienes instalados.
Lo que cuesta. Dinero, nada: las reglas viven en ficheros de ajustes y funcionan igual con suscripción que con clave de API. Lo que cuesta es atención. Cada ask es una pregunta que tienes que contestar, y un montaje que pregunta demasiado acaba con alguien pulsando «sí» sin leer; eso protege menos que tener menos preguntas bien elegidas. I
Negar una herramienta entera tiene una ventaja extra: deja de ocupar contexto, porque el modelo ya no la ve. V La documentación no da cifras de cuánto ahorra, y no las inventamos.
Cuándo no conviene fiarse solo de las reglas.
npx * o docker exec *: estás permitiendo cualquier orden. VPor dónde empezar. Esto es propuesta nuestra, no de la documentación. I
/permissions y lee lo que ya tienes, sobre todo lo que viene de .claude/settings.local.json, que se llena con cada «sí, y no vuelvas a preguntar»..claudeignore a reglas deny de Read, como Read(./.env) o Read(./secretos/**). Vclaude --version.Hasta dónde llega: una regla de permisos mira el nombre de la herramienta y el texto de la llamada. No ve lo que hará una orden al ejecutarse, y sin ajustes gestionados un mod instalado puede pasar por encima. Para lo que no puede ocurrir nunca, el sandbox y las credenciales de alcance mínimo.
Marca las que se cumplan en tu caso.
Usa el laboratorio de arriba con tu propio caso.
Las piezas que lo completan.
Si algo no encaja con tu caso, o si encuentras un error, escríbeme: se corrige y se anota.
Escríbeme