“Ændr venligst kun kladderne” er en fornuftig arbejdsinstruks. Men det er endnu ikke et teknisk kontrolpunkt. En hook kan anvende en tilbagevendende regel på det tidspunkt, hvor en bestemt handling er forberedt. Det gør en generel anmodning til en efterprøvelig beslutning om et bestemt værktøjskald.
I Claude Code-referencen beskrives blandt andre hændelser PreToolUse: den indtræffer, efter at værktøjsparametrene er oprettet, og før kaldet behandles. Hooken kan returnere en beslutning. De følgende eksempler forklarer et udkast, vi selv har lavet; der blev ikke installeret eller kørt nogen hook-konfiguration til dem.
Hvilke oplysninger er tilgængelige ved beslutningspunktet?
Vores læringsprojekt indeholder en kladdemappe og en referencefil ved siden af. Agenten må kun redigere kladder. En fornuftig regel ser derfor på det konkrete mål for en skrivehandling. Den afgør ikke, om hele samtalens indhold er troværdigt.
Grænsefladen leverer værktøjsnavnet og inputtet. For en passende filanmodning kan målet bestemmes ud fra dem. Et ukendt værktøj eller et uforståeligt input bør udløse en særskilt tilstand. En tavs fejl i kontrolprogrammet må ikke ligne en succesfuldt kontrolleret sti.
En beslutning er en struktureret returværdi
En illustrativ afvisningsværdi i den dokumenterede PreToolUse-struktur ser sådan ud. Begrundelsen er vores egen formulering; den beskriver den lokale regel, ikke en generel vurdering af brugeren.
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "The target file is outside the drafts area."
}
}Dette uddrag er returværdien, ikke et komplet kontrolprogram. Det indeholder hverken registreringen af hooken eller indlæsningen og kontrollen af inputtet. Netop denne adskillelse er nyttig: reglen, den tekniske evaluering og grænsefladens output kan betragtes hver for sig.
At høre til en sti er mere end et matchende præfiks
En ren sammenligning af tegnstrenge kan forveksle nabomapper med lignende navne. Din egen regel bør derfor arbejde med entydigt opløste stier og kontrollere, om målet faktisk hører til den tiltænkte rodmappe. Forskellige separatorer og links skal tages i betragtning i det anvendte miljø.
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.Denne skitse antyder bevidst ikke fuldstændig beskyttelse. Især eksterne programmer, der selv ændrer yderligere filer, kræver andre overvejelser end et enkelt filfelt. En tilladt startfil siger endnu intet om, hvilke opfølgende handlinger et script udfører.
Fire prøver gør rækkevidden synlig
Opret i et engangsprojekt en tilladt fil, en beskyttet reference og en nabomappe med et lignende navn. Tilføj et ugyldigt input. Skriv for hvert tilfælde på forhånd ned, hvilken beslutning der forventes. Se derefter både på returværdien og på den faktiske udførelse.
Test også et nedbrud i selve kontrolprogrammet. Fejladfærden afhænger af hændelsen og konfigurationen og er derfor en del af accepten. En manglende meddelelse er intet bevis for, at reglen blev kontrolleret med succes.
Notér også for hver prøve, om hooken overhovedet blev nået. En handling, der tager en anden vej, kan omgå reglen, uden at dens interne stikontrol har fungeret forkert.
En hook er ikke en komplet beskyttelsesramme
PreToolUse vedrører værktøjskald. Kontekst kan komme ind i sessionen ad andre veje; den aktuelle reference beskriver udtrykkeligt begrænsninger på dette punkt. En hook erstatter derfor hverken tilladelser eller kontrol med miljøet, og den er ikke en generel beskyttelse mod prompt injection.
Start med en enkelt lokal regel, og dokumentér de veje, den dækker og ikke dækker. Den tekniske gevinst ligger i et forståeligt kontrolpunkt. Om dette kontrolpunkt er sat korrekt op i din version, må et faktisk forsøg med de relevante grænseflader vise.
Kilder og dokumentationsstatus: 25. oktober 2026.
