Saltar al contenido
kenjtecJournal
Buscar en el Journal

Hooks de Claude Code: las reglas recurrentes se convierten en pasos fijos del flujo de trabajo

Los hooks se enganchan a eventos del flujo de trabajo de Claude Code. Una pequeña protección contra escritura muestra la salida de decisión, la comprobación de rutas y los límites de un control así.

Lena hace rodar piezas de bicicleta por una pequeña rampa hasta una puerta de control; una pieza de referencia está dentro de un recipiente de vidrio. Ilustración creada con IA.

«Por favor, cambia solo los borradores» es una instrucción de trabajo sensata. Pero todavía no es un punto de control técnico. Un hook puede aplicar una regla recurrente en el momento en que se ha preparado una acción concreta. Así, una petición general se convierte en una decisión verificable sobre una llamada a herramienta concreta.

La referencia de Claude Code describe, entre otros eventos, PreToolUse: se produce después de que se hayan creado los parámetros de la herramienta y antes de que se procese la llamada. El hook puede devolver una decisión. Los siguientes ejemplos explican un borrador propio; para ellos no se instaló ni se ejecutó ninguna configuración de hooks.

¿Qué información está disponible en el punto de decisión?

Nuestro proyecto de aprendizaje contiene una carpeta de borradores y, junto a ella, un archivo de referencia. El agente solo debe editar borradores. Por tanto, una regla sensata se fija en el destino concreto de una acción de escritura. No decide si todo el contenido de la conversación es fiable.

La interfaz proporciona el nombre de la herramienta y la entrada. En una solicitud de archivo adecuada, el destino puede determinarse a partir de ellos. Una herramienta desconocida o una entrada incomprensible deberían provocar un estado propio. Un error silencioso en el programa de comprobación no debe parecer una ruta comprobada con éxito.

Una decisión es un valor de retorno estructurado

Un valor de denegación ilustrativo con la estructura documentada de PreToolUse tiene este aspecto. El motivo es una redacción propia; describe la regla local, no una valoración general del usuario.

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "The target file is outside the drafts area."
  }
}

Este fragmento es el valor de retorno, no un programa de comprobación completo. No contiene ni el registro del hook ni la lectura y comprobación de la entrada. Precisamente esta separación es útil: la regla, la evaluación técnica y la salida de la interfaz pueden examinarse por separado.

Pertenecer a una ruta es más que un prefijo coincidente

Una simple comparación de cadenas de caracteres puede confundir carpetas vecinas con nombres parecidos. Por eso, tu propia regla debería trabajar con rutas resueltas de forma inequívoca y comprobar si el destino pertenece realmente a la carpeta raíz prevista. En el entorno utilizado hay que tener en cuenta los distintos separadores y enlaces.

own rule logic, schematic:
  Input fully readable? Otherwise check status unknown.
  Tool belongs to the write path being handled? Otherwise not checked.
  Resolve target and permitted root unambiguously.
  Target really inside the root? Otherwise deny.
  Assess only the specific call being handled.

Este esbozo no pretende, de forma deliberada, ofrecer una protección completa. En particular, los programas externos que a su vez modifican otros archivos requieren una consideración distinta a la de un único campo de archivo. Un archivo de inicio permitido todavía no dice nada sobre qué acciones posteriores lleva a cabo un script.

Cuatro pruebas hacen visible el alcance

En un proyecto desechable, crea un archivo permitido, una referencia protegida y una carpeta vecina con un nombre parecido. Añade una entrada no válida. Para cada caso, anota de antemano qué decisión se espera. Después, examina tanto el valor de retorno como la ejecución real.

Prueba también un fallo del propio programa de comprobación. El comportamiento ante fallos depende del evento y de la configuración y, por tanto, forma parte de la aceptación. La ausencia de un mensaje no demuestra que la regla se haya comprobado con éxito.

En cada prueba, anota también si se llegó a alcanzar el hook. Una acción que toma otra vía puede eludir la regla sin que su comprobación interna de rutas haya funcionado mal.

Un hook no es un marco de protección completo

PreToolUse se refiere a las llamadas a herramientas. El contexto puede entrar en la sesión por otras vías; la referencia actual describe explícitamente límites en este sentido. Por tanto, un hook no sustituye ni los permisos ni el control del entorno, y no es una protección general contra la inyección de prompts.

Empieza con una sola regla local y documenta las vías que cubre y las que no cubre. La ventaja técnica reside en un punto de control comprensible. Si este punto de control está bien configurado en tu versión es algo que debe demostrar una prueba real con las interfaces adecuadas.

Fuentes y estado de la documentación: 25 de octubre de 2026.

Hamburgo es nuestro punto de partida.

Lo útil viaja contigo.

IA práctica desde Hamburgo, explicada para todos.

Artículos guardados