Saltar al contenido
MaestrIA

Formación › Programar con Claude Code en 12 horas › Hora 7

Programar con Claude Code en 12 horas · hora 7 de 12

Permisos, modos y seguridad

Claude Code puede ejecutar cualquier comando que tú podrías ejecutar. Los permisos deciden qué hace solo, qué te pregunta y qué no hace nunca. Verás dos sesiones reales en las que los permisos frenaron al agente, y lo que intentó para seguir adelante.

Al terminar sabrásElegir el modo de permisos adecuado para una tarea, escribir reglas allow, ask y deny prediciendo qué pasará con cada comando, y explicar por qué una regla debe cubrir todas las vías de un agente.

60 minutos· 2 esquemas· 7 preguntas· 1 ejercicio· entregable

Repaso

Comprueba De la hora 6: ¿qué hace una buena spec con una decisión de negocio?

Comprueba De la hora 5: Claude dice «todo funciona» sin enseñar nada. ¿Qué pides?

Vocabulario

Modo de permisos
La regla general de lo que Claude hace sin preguntar: manual, aceptar ediciones, plan, automático, dontAsk o bypass.
Regla allow, ask o deny
Una regla concreta que permite, pregunta o prohíbe una herramienta o un comando, como Bash(npm test).
Ruta protegida
Carpetas y ficheros que Claude Code no escribe sin tu confirmación, como .git y .claude.
Clasificador
El modelo aparte que, en modo automático, revisa cada acción y bloquea lo arriesgado.
Sandbox (aislamiento)
Un límite que pone el sistema operativo a los comandos de Claude: a qué ficheros y a qué dominios de red pueden llegar.

El ejemplo: dos frenos reales

Dos sesiones reales sobre el repositorio de práctica, en las que los permisos pararon al agente.

Antes y después Modo dontAsk: lo que te preguntaría, se deniega

Antes y después Ruta protegida: .claude/

La petición

En modo de aceptar ediciones
Configura en .claude/settings.json un hook que bloquee cualquier edición de ficheros dentro de la carpeta datos/ […]

La sesión real

Salida real Claude Sonnet 5.5 · 24 de octubre de 2026 · sin editar · Claude Code en modo acceptEdits sobre el repositorio de práctica

Para repetirla, en el repositorio: claude --permission-mode acceptEdits y pega la petición. Se grabó con claude -p, sin conversación: lo que aquí se deniega, a ti te lo preguntaría.

Lo que hizo: 3 acciones
  • Bash: ls -la .claude .claude/hooks datos 2>&1; cat .claude/settings.json 2>&1; node --version
  • Write: .claude/hooks/bloquear-datos.js
  • Write: .claude/settings.json

No he podido crear los ficheros: Claude Code ha denegado los dos permisos de escritura, el de .claude/hooks/bloquear-datos.js (lo trata como fichero sensible) y el de .claude/settings.json. No he intentado esquivarlo escribiendo por otra vía. Hasta que lo autorices, el hook no existe.

Para continuar, concede el permiso de escritura sobre .claude/ (o confírmame que lo haga por otra vía) y repito las dos escrituras. Esto es lo que pensaba crear:

.claude/settings.json
```json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write|MultiEdit|NotebookEdit",
"hooks": [
{
"type": "command",
"command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/bloquear-datos.js\""
}
]
}
]
}
}
```

.claude/hooks/bloquear-datos.js

  • Lee el JSON del evento por stdin, sin jq, solo con Node (v24 instalado).
  • Toma tool_input.file_path (o notebook_path) y lo resuelve a ruta absoluta.
  • Comprueba con path.relative si queda dentro de <proyecto>/datos. Así cubre rutas relativas, absolutas y con .., y compara sin distinguir mayúsculas en Windows.
  • Si está dentro, termina con código 2 y escribe en stderr el motivo: son datos de origen que no se modifican a mano, y la alternativa es generar una copia derivada fuera de datos/.
  • Si la entrada no se puede leer, deja pasar la operación, para que un fallo del hook no bloquee todo el trabajo.

Límite: el hook solo cubre las herramientas de edición de Claude. Un comando de Bash, como echo > datos/paradas.csv, no pasaría por él. Si quieres cubrirlo también, puedo añadir un segundo matcher para Bash, aunque sería una comprobación aproximada.

Qué ha pasado

En modo de aceptar ediciones, escribir dentro de .claude/ pide confirmación, porque es una ruta protegida; en una ejecución sin nadie que conteste, se deniega. Esta vez Claude no buscó otra vía: dijo que no lo había hecho para no saltarse la denegación y explicó qué habría escrito. En la hora 10 verás la misma tarea en modo automático, donde sí se hizo.

Los modos de permiso

Según la documentación (consultada el 24/10/2026):

ModoQué hace sin preguntar
Manual (default)Leer y comandos de solo lectura; pregunta antes de editar, ejecutar o usar la red
Aceptar ediciones (acceptEdits)Leer, editar y comandos de ficheros comunes en tu carpeta
Plan (plan)Leer e investigar; no edita hasta que apruebes un plan
Automático (auto)Todo, con un clasificador que bloquea lo arriesgado
dontAskLo mismo que manual sin preguntar, más lo permitido de antemano; lo demás se deniega
bypassPermissionsTodo; solo para entornos aislados, como contenedores

Desde la versión 2.1.283, el modo automático es el de inicio en la terminal y en VS Code. En claude -p sin modo indicado, desde la 2.1.302, se empieza en manual y se deniega lo que necesitaría confirmación. La documentación advierte de que el modo automático reduce las preguntas, pero no garantiza la seguridad.

Las reglas: deny, después ask, después allow

Cómo decide Claude Code si puede hacer algoCada acción pasa por las reglas en orden: si coincide con una regla deny se bloquea; si no, si coincide con ask se pregunta; si no, si coincide con allow se permite; si no coincide con ninguna, decide el modo de permisos.Acciónp. ej. Bashdeny¿coincide?sí → bloqueanoask¿coincide?sí → preguntanoallow¿coincide?sí → permitenoEl mododecideUn allow nunca abre una excepción dentro de un deny.Un hook que sale con código 2 bloquea antes incluso de mirar las reglas.
El orden en que se evalúan las reglas. Un allow nunca abre una excepción dentro de un deny.

Las reglas van en .claude/settings.json y se evalúan en orden: deny, después ask y después allow. La primera que coincide decide, y la especificidad no cambia el orden. Por eso un deny amplio como Bash(aws *) bloquea también aws s3 ls aunque tengas un allow para él. Además, las rutas protegidas como .git y .claude no se autorizan con reglas allow: dependen del modo.

.claude/settings.json (ejemplo)
{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(npm run *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Bash(rm *)", "Read(./.env)"]
  }
}

Lo que una regla de Bash no frena

Una regla de Bash compara el texto del comando que escribe Claude. La documentación lo dice sin rodeos: no es una barrera de seguridad alrededor del programa. Bash(rm *) en deny frena rm -rf build/, pero no /bin/rm -rf build/ ni bash -c 'rm -rf build/', y tampoco find build -delete, que es otro programa. Esos comandos los decide el resto de tus reglas y el modo.

Para un límite que no dependa de cómo se escriba el comando hay dos herramientas:

  • El sandbox: el sistema operativo limita a qué ficheros y dominios de red llegan los comandos de Claude. Se activa con /sandbox en la sesión y viene apagado. Funciona en macOS, Linux y WSL2; en Windows sin WSL2, los comandos se ejecutan sin aislar.
  • Un hook PreToolUse que mire el comando completo antes de ejecutarlo (hora 10).

Practica

Clasifica Con las reglas del ejemplo y en modo manual, ¿qué pasa con cada acción?

  1. npm test
  2. npm run parte
  3. git push origin main
  4. rm -rf datos
  5. Leer el fichero .env
  6. npm install
  7. find datos -delete

Elige un agente, marca qué ingredientes tiene y comprueba tu juicio.

Ingredientes

Con los tres ingredientes a la vez, una instrucción escondida en un correo o una web puede hacer que el agente envíe tus datos fuera. La defensa práctica es quitar uno de los tres, no confiar en que el modelo lo detecte.

Recuerda la trifecta: los permisos son tu forma de quitar un ingrediente.

Comprueba lo que has aprendido

Comprueba En la sesión dontAsk, Claude intentó borrar con Bash, con la herramienta de escritura y con PowerShell. ¿Qué enseña?

Comprueba Tienes allow: ["Bash(aws s3 ls)"] y deny: ["Bash(aws *)"]. ¿Qué pasa con aws s3 ls?

Comprueba Tienes Bash(rm *) en deny y Claude propone find datos -delete. ¿Qué lo decide?

Comprueba Vas a dejar a Claude trabajando solo en un script de CI. ¿Qué modo eliges?

Comprueba La trifecta letal junta tres cosas en un mismo agente. ¿Cuáles?

Entregable Tus permisos de proyecto

Escribe el .claude/settings.json del repositorio de práctica o de tu proyecto con reglas allow, ask y deny. Para cinco comandos reales, predice qué pasará y compruébalo en una sesión. Incluye uno que esquive una regla de Bash, como find … -delete frente a Bash(rm *). Pega aquí las reglas, tus predicciones y los resultados.

Está bien si: cada predicción dice qué regla o qué modo decide; al menos una predicción falló y explicas por qué; y propones qué cubre lo que la regla de Bash no frena. Tiempo: unos 25 minutos.

Lo esencial

  • Elige el modo según la tarea: plan para explorar, automático para trabajar, dontAsk para lo desatendido y bypass solo en entornos aislados.
  • Las reglas se evalúan deny, ask y allow: un allow nunca abre excepciones dentro de un deny.
  • Las rutas protegidas, como .claude y .git, no se autorizan con reglas: dependen del modo.
  • Un agente puede buscar otra vía cuando una falla: protege todas, no una.
  • Una regla de Bash mira el texto del comando; para un límite real, sandbox o hook.

Fuentes y para seguir

← Hora 6Desarrollo guiado por especificacionesHora 8 →Skills (y comandos)

Lección revisada el 24/10/2026 con la documentación oficial enlazada en sus fuentes. Revisamos los cursos cada trimestre.