Hookok a Claude Code-ban 2026-ban: lépésről lépésre történő beállítás és 7 azonnal használható példa

A Claude Code hookjai olyan shell-parancsok, HTTP-hívások vagy rövid LLM-ellenőrzések, amelyek automatikusan lefutnak egy Claude-művelet előtt vagy után. Meghatározott eszközeseményekhez adnak ellenőrzéseket, szerkesztés után formázzák a kódot, és a munkamenet elején friss kontextust illesztenek be. Egy illeszkedő PreToolUse hook visszautasíthatja az adott hívást; ezek a reguláris kifejezéses példák kényelmi védőkorlátok, nem minden fájl- és Git-hozzáférési útra kiterjedő biztonsági határok. Az alábbiakban bemutatjuk a 4 kezelőtípust, a 31 életciklus-eseményt, egy tesztet annak eldöntésére, hogy „mikor való egy szabály hookba”, 7, a .claude/settings.json fájlba másolható hookot, valamint 3 saját tapasztalatból ismert buktatót.

Ailoot-dokumentáció: API, kulcsok és beállítás.

Mik azok a hookok a Claude Code-ban?#

Fél éven át a „soha ne szerkeszd közvetlenül a .env fájlt” szabályt a CLAUDE.md fájlban tartottam. Claude havonta egyszer megszegte. Nem szándékosan; egyszerűen elfelejtette egy hosszú munkamenet végére. Egyszer egy plusz token került a .env fájlba, máskor pedig egy duplikált nevű változó felülírta a használatban lévőt.

Áttettem a szabályt egy hookba, így lehetetlenné vált elfelejteni. Ha egy illeszkedő közvetlen szerkesztőeszköz .env-útvonalat ad át, a beállított hook visszautasítja azt a hívást. A Bash-átirányításokhoz, szkriptekhez, MCP-eszközökhöz és más hozzáférési utakhoz külön korlátozások kellenek; ez a példa nem teszi módosíthatatlanná a fájlt.

Más szóval a hook az Ön által megadott parancs, amelyet a Claude Code egy adott eseménynél futtat le. Minden fájlszerkesztés, Bash-indítás, munkamenet-kezdés vagy alügynök-befejezés olyan esemény, amelyhez hookot lehet rendelni.

Miért fontos ez egy vibe coder számára:

• Védje meg a titkokat tartalmazó fájlokat a véletlen szerkesztéstől.
• Minden kódgenerálás után futtassa automatikusan a prettier/eslint eszközt.
• Kifejezett engedély nélkül tiltsa le a git push --force parancsot a main ágra.
• Szúrjon be friss kontextust minden munkamenet kezdetén.
• Naplózza Claude műveleteit auditálás céljából.

A CLAUDE.md a kontextust kezeli. A hookok a műveleteket kezelik. Két külön dologról van szó, és összekeverésük a kezdők leggyakoribb hibája.

Miben különböznek a hookok a CLAUDE.md-től és a skillektől?#

Az Anthropic dokumentációja kifejezetten elmagyarázza a CLAUDE.md és a hookok közti különbséget:

Másként fogalmazva: a CLAUDE.md tartalma a felhasználótól érkező első üzenetként jut el Claude-hoz, nem rendszerszintű utasításként. A modell elolvassa, és megpróbálja követni. Garancia azonban nincs, különösen egy hosszú munkamenet vége felé, amikor a kontextus megnő, a régebbi utasítások pedig kiszorulnak belőle.

A hook másképp működik. A settings.json fájlban található, nem függ a modelltől, és a Claude Code-folyamat futtatja egy adott eseménykor: például PreToolUse, PostToolUse, SessionStart esetén. A parancs még azelőtt lefut, hogy Claude megkapná az eredményt, és fizikailag is megakadályozhat egy műveletet (exit 2), vagy szerkesztés után módosíthat egy fájlt (exit 0).

Összehasonlítás:

A teljes CLAUDE.md-sablon és az élő dokumentumra vonatkozó 6 szabály megtalálható az A CLAUDE.md beállítása 2026-ban: használatra kész sablon és 6 szabály című útmutatóban. A skillekről mint névvel ellátott képességekről a Claude Code Skills: saját könyvtár építése útmutatóban olvashat.

A hook a legalacsonyabb szint: nincs modell, nincs értelmezés, csak shell.

A hookok a kontextusmérnöki eszközök egyike, a Plan Mode és a /compact mellett.

4 hooktípus: Command, HTTP, Prompt, Agent — melyiket válassza?#

A leggyakoribb hiba, hogy valaki Commanddal próbálja megoldani azt, amihez Prompt kellene. Például a „ne használj gondolatjelet a .md fájlokban” grep-fel ellenőrizhető feladat, ezért a Command ideális. A „ne írj vállalati hangnemben” viszont szemantikai kérdés, ezért Prompt szükséges hozzá.

Ha most kezdi, használja a Commandot. Az alábbi 7, azonnal használható hook mind Command. A HTTP/Prompt/Agent később jön, amikor készen áll rájuk.

Hol található a settings.json, és mi a 4 konfigurációs szint?#

Az alább ismertetett 7 hookot a projekt .claude/settings.json fájljában tartom, így a tár klónozásakor automatikusan bekerülnek, és Claude új ablakban is ugyanazokat a szabályokat követi. A személyes kísérleti hookok a .claude/settings.local.json fájlba kerülnek, hogy ne zavarják a csapat munkáját.

Mind a 4 fájl összeolvad a munkamenet kezdetén. Ütköző szabályok esetén az alacsonyabb szint élvez elsőbbséget (a helyi a projekttel, a projekt a felhasználóival szemben).

Az első hook létrehozásának leggyorsabb módja a Claude Code-on belüli interaktív /hooks menü. Válasszon egy eseményt a listából, állítson be matchert (például Bash vagy Edit), majd illesszen be egy parancsot. A Claude Code érvényes JSON-t ír a settings.json fájlba.

31 életciklus-esemény: melyekre van szüksége a kezdőknek?#

Fontos megérteni a három gyakoriságot, hogy ne keveredjen össze:

1. Egyszer munkamenetenként - SessionStart, SessionEnd, Setup. Ezek egyszer futnak le, amikor a Claude Code megnyílik és bezárul. Használja őket a kontextus előkészítésére és az ideiglenes fájlok eltávolítására.
2. Egyszer fordulónként - UserPromptSubmit, UserPromptExpansion, Stop, StopFailure. Ezek minden üzeneténél és minden alkalommal lefutnak, amikor a modell megáll. Használja őket a beszélgetés naplózására és a végeredmény ellenőrzésére.
3. Minden eszközhíváskor - PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest, PermissionDenied, PostToolBatch, SubagentStart, SubagentStop. Ezek minden fájlszerkesztésnél, Bash-indításnál, olvasásnál vagy keresésnél lefutnak. Ez a leggyakrabban aktiválódó réteg; itt élnek a korlátozások, a formázás és a validálás.

A 31 esemény teljes listája aszinkron/reaktív eseményeket is tartalmaz: TeammateIdle, PreCompact, PostCompact, Elicitation, ElicitationResult, InstructionsLoaded, ConfigChange, CwdChanged, FileChanged, WorktreeCreate, WorktreeRemove, Notification. Ezek haladó helyzetekhez valók; egyelőre hagyja ki őket.

Ötkérdéses teszt: mikor való egy szabály hookba, és mikor maradjon a CLAUDE.md-ben?#

Számomra ez törvényként működik, nem javaslatként. A CLAUDE.md és a hook közötti választást egy egyszerű, ötkérdéses tesztre szűkítettem. Ha legalább három válasz „igen”, a szabály hookba kerül. Háromnál kevesebb igen esetén marad a szövegben.

A „mikor való egy szabály hookba?” teszt:

1. Ez a szabály műveletről szól, nem kontextusról? („ne futtasd az rm -rf parancsot” művelet; „TypeScript-projektem van” kontextus.)
2. Biztonságról, pénzről vagy adatról szól? („ne nyúlj a .env fájlhoz”, „ne tedd közzé a kulcsokat”.)
3. Ellenőrizhető greppel, regexszel vagy egy shell-parancs kilépési kódjával? („a .md szerkesztése után ellenőrizd, hogy nincs-e benne gondolatjel.”)
4. Ha megszegik a szabályt, fájdalmas lenne visszafordítani a következményeket? („force push a main ágra” nehezen visszafordítható; „elfelejtettem a mondat végi pontot” könnyen javítható.)
5. Látta már legalább egyszer, hogy Claude megfeledkezik erről a szabályról?

Példa: „Ne használj gondolatjelet; csak kötőjelet használj.” Művelet? Igen. Biztonság? Nem. Greppel ellenőrizhető? Igen. Nehéz visszafordítani? Nem. Látta már megszegve? Igen. 3 az 5-ből: kerüljön hookba.

Ellenpélda: „Vibe codereim vannak, nem fejlesztőim; szleng nélkül írj.” Művelet? Inkább kontextus. Biztonság? Nem. Regexszel ellenőrizhető? Túl nehéz. Nehéz visszafordítani? Nem. Látta már megszegve? Igen. 1 az 5-ből: maradjon a CLAUDE.md fájlban.

Öt szabályom megfelelt a teszten. Ezek átkerültek a hookokba. A fennmaradó 75% a szövegfájlban maradt.

7 azonnal másolható hook#

Mind a 7 hook egyetlen .claude/settings.json fájlban található a projekt gyökerében. Minden bejegyzéshez tartozik egy eseménytípus, egy eszközszűrő (matcher) és egy shell-parancs. A 2-es kilépési kód egy illeszkedő PreToolUse hívást végrehajtás előtt utasít vissza. PostToolUse esetén a művelet már megtörtént: a hook visszajelzést ad, de nem tudja visszavonni.

Az exit 0 sikert jelent. Az exit 1 hibát jelez, de Claude folytatja (ez az első alább bemutatott antipattern). Az exit 2 hatása eseményfüggő: PreToolUse esetén blokkolhat, míg PostToolUse esetén csak visszajelzést ad a már elvégzett műveletről.

1. hook. A .env közvetlen szerkesztéseinek ellenőrzése (PreToolUse, exit 2)

Blokkolja minden olyan fájl közvetlen szerkesztésére tett kísérletet, amely illeszkedik a .env, .env.local, .env.production stb. mintára.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "FILE=$(jq -r '.tool_input.file_path // empty'); [ -z \"$FILE\" ] && exit 0; echo \"$FILE\" | grep -qE '(^|/)\\.env(\\.|$)' && { echo 'Do not edit `.env` directly. Tell me which variable to add, and I’ll open the file myself.' >&2; exit 2; } || exit 0"
          }
        ]
      }
    ]
  }
}

Mit csinál: Minden Edit/Write/MultiEdit előtt lekéri a fájl útvonalát, greppel ellenőrzi, hogy illeszkedik-e a .env mintára, és ha igen, 2-es kilépési kódot ad vissza egy üzenettel. Claude látja a stderr kimenetét, és ezt mondja nekem: „Megpróbáltam szerkeszteni a .env fájlt, de a hook blokkolt; mondd meg, melyik változót adjam hozzá.”

2. hook. A prettier automatikus futtatása minden kódszerkesztés után (PostToolUse, exit 0)

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "FILE=$(jq -r '.tool_input.file_path // empty'); [ -z \"$FILE\" ] && exit 0; echo \"$FILE\" | grep -qE '\\.(ts|tsx|js|jsx|json)$' && npx prettier --write \"$FILE\" 2>/dev/null & exit 0"
          }
        ]
      }
    ]
  }
}

Mit csinál: Minden Edit/Write után lekéri az útvonalat, és ha a kiterjesztés .ts/.tsx/.js/.jsx/.json, a prettier eszközt a háttérben, & jellel indítja el. Mindig 0-s kilépési kódot ad, mert ez formázás, nem korlátozás. Ha a prettier hibát jelez, az nem nagy ügy; a fájl változatlan marad.

Az 1. hooktól alapvetően különbözik: a PreToolUse + exit 2 kemény blokkolás a művelet előtt. A PostToolUse + exit 0 puha módosítás a művelet után. Ez két különböző mód, kétféle feladathoz.

3. hook. A git push --force letiltása a main ágra (PreToolUse, exit 2)

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "CMD=$(jq -r '.tool_input.command // empty'); [ -z \"$CMD\" ] && exit 0; echo \"$CMD\" | grep -qE 'git[[:space:]]+push' && echo \"$CMD\" | grep -qE '(\\-\\-force|\\-\\-force-with-lease|[[:space:]]-f([[:space:]]|$))' && echo \"$CMD\" | grep -qE '([[:space:]/:])main([[:space:]/:]|$)' && { echo 'Force push to main is forbidden. Create a new branch or ask me to do it manually.' >&2; exit 2; } || exit 0"
          }
        ]
      }
    ]
  }
}

Mit csinál: Minden Bash-indításkor ellenőrzi, hogy a parancs tartalmazza-e a push szót, a --force/--force-with-lease/-f valamelyikét, és megemlíti-e a main ágat. Ha mindhárom feltétel teljesül, egyértelmű üzenettel blokkolja.

Régebben ezt a szabályt csupa nagybetűvel írtam a CLAUDE.md fájlba. Claude mégis körülbelül kéthetente megszegte, amikor azt kértem tőle, hogy „force push a hibás commitom visszavonásához”. Ez a hook a bemutatott, szó szerint szereplő parancsalakokat fogja meg, de aliasok, szkriptek, ki nem írt célág vagy más Git-kliens kikerülhetik a szöveges ellenőrzést. A main ág védelmét a távoli tárban érvényesítse, és korlátozza az ügynök rendelkezésére álló hitelesítő adatokat.

4. hook. A gondolatjelek letiltása szövegfájlokban (PostToolUse, exit 2)

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "FILE=$(jq -r '.tool_input.file_path // empty'); [ -z \"$FILE\" ] && exit 0; echo \"$FILE\" | grep -qE '\\.(md|mdx|tsx?)$' && grep -q $'\\xe2\\x80\\x94' \"$FILE\" && { echo \"File $FILE contains an em dash (U+2014). Replace it with a regular hyphen (U+002D).\" >&2; exit 2; } || exit 0"
          }
        ]
      }
    ]
  }
}

Mit csinál: A PostToolUse exit 2-vel a szerkesztés után jelenti Claude-nak az utóellenőrzés hibáját. Nem vonja vissza és nem akadályozza meg az írást. Ha Claude szerkesztett egy fájlt, de benne hagyott egy gondolatjelet, a hook hibát ad, Claude visszajelzést kap, és újra próbálkozik. 2–3 munkamenet után Claude teljesen abbahagyja ennek a karakternek a beszúrását.

Fontos, hogy a grep kifejezetten a gondolatjel karaktert (U+2014) keresi a $'\xe2\x80\x94' kifejezéssel, amely a karakter UTF-8-bájtokként történő leírására szolgáló Bash-jelölés. Ha egyszerűen grep -q '-' formában írnánk, az a normál kötőjeleket is megtalálná, és minden fájlon lefutna. Egy láthatatlan karakter tönkreteszi a teljes logikát.

5. hook. A 3000-es port felszabadítása az npm run dev előtt (PreToolUse, exit 0)

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "CMD=$(jq -r '.tool_input.command // empty'); [ -z \"$CMD\" ] && exit 0; echo \"$CMD\" | grep -qE '(npm|pnpm|yarn)[[:space:]]+run[[:space:]]+dev' && { lsof -ti:3000 | xargs -r kill -9 2>/dev/null; echo 'Port 3000 freed before launch' >&2; }; exit 0"
          }
        ]
      }
    ]
  }
}

Mit csinál: Minden npm run dev (vagy pnpm/yarn) előtt leállítja a 3000-es porton futó folyamatot. Mindig 0-s kilépési kódot ad, mert ez előkészítés, nem korlátozás. Ezzel elkerülhető az a csapda, amikor Claude azt látja, hogy „a port használatban van”, kódhibára gyanakszik, és javítgatni kezd, holott csak a régi szerver maradt futva.

6. hook. Automatikus commit sikeres tesztek után (PostToolUse, exit 0)

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "INPUT=$(cat); CMD=$(printf '%s' \"$INPUT\" | jq -r '.tool_input.command // empty') || exit 1; EXIT=$(printf '%s' \"$INPUT\" | jq -r '.tool_response.exit_code // empty') || exit 1; case \"$CMD\" in 'npm test'|'pnpm test'|'yarn test') ;; *) exit 0 ;; esac; [ \"$EXIT\" = \"0\" ] || exit 0; git diff --cached --quiet || { echo 'Existing staged changes: review manually' >&2; exit 0; }; git add -- src/orders.ts tests/orders.test.ts || exit 1; git diff --cached --quiet && exit 0; git commit -m 'tests: checkpoint after successful run'"
          }
        ]
      }
    ]
  }
}

Mit csinál: Egyszer olvassa be a JSON stdin-bemenetet, és csak a bemutatott, pontos, önálló tesztparancsokat fogadja el. Csak akkor folytatja, ha a megadott tool_response.exit_code kifejezetten nulla; ha a telepített verzió nem adja át ezt a mezőt, a siker feltételezése helyett kihagyja a commitot. A src/orders.ts és tests/orders.test.ts helyére a feladathoz tartozó pontos fájlokat írja. A már előkészített változások leállítják ezt a receptet, hogy idegen munka ne kerüljön bele. Sikertelen hozzáadásnál leáll, üres diffből nem készít commitot, a szokásos commithookokat pedig bekapcsolva hagyja. Engedélyezés előtt offline tesztelje a sikeres, sikertelen és hiányzó eredményű bemeneteket.

Antipattern: git commit --no-verify hozzáadása minden Edit után. Hagyja bekapcsolva a commitellenőrzéseket. Ha egy ellenőrzés rekurzívan újra elindítja az automatizmust, szűkítse a kiváltó feltételt vagy alakítsa át az ellenőrzést; alapértelmezésként ne kerülje meg a vizsgálatot. Az automatikus commitok engedélyezése előtt tekintse át az előkészített diffet és a feladathoz tartozó fájlokat.

7. hook. Friss kontextus beszúrása munkamenet-kezdéskor (SessionStart additionalContext mezővel)

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "BRANCH=$(git symbolic-ref --short HEAD 2>/dev/null || echo 'no-branch'); STATUS=$(git status --short 2>/dev/null | head -10); echo \"{\\\"additionalContext\\\":\\\"Current branch: $BRANCH. Uncommitted changes:\\n$STATUS\\\"}\""
          }
        ]
      }
    ]
  }
}

Mit csinál: A munkamenet elején összegyűjti az aktuális Git-ágat és a commitolatlan változások listáját, majd egy additionalContext mezőt tartalmazó JSON-t ad vissza. A Claude Code ezt a szöveget az első rendszerüzenetbe illeszti, így Claude kezdettől tudja, hol tart és mi maradt az előző munkamenetből.

A hook további bővítései: kérje le a legutóbbi commitot és annak leírását, a GitHub Actions állapotát, az aktív sprintet Linear/Jira rendszerből, valamint az aktuális tár nyitott ügyeit.

3 hookbuktató, amely minden második embert érint#

1. buktató. Az exit 1-et adó hook csendben továbbenged

Ez a legveszélyesebb. Egy héten át azt hittem, hogy az .env-védőm működik, de kiderült, hogy a hookban a jq -r '.tool_input.file_path' parancsot használtam null-ellenőrzés nélkül. Ha a tool_input üres volt, a jq 1-es kóddal lépett ki. Claude az exit 1-et úgy értelmezte, hogy „hookhiba, folytatás”, ezért a művelet végrehajtódott. Nem értettem, miért nyúlnak továbbra is a .env fájlhoz. Csak akkor jöttem rá az okára, amikor üres bemenettel, kézzel futtattam a hookot a terminálban.

A javítás egyetlen szabály: minden hook elején ellenőrizze, hogy az érték null-e, és a végére tegyen || exit 0 részt. Így minden váratlan kilépés „biztonságos” kilépéshez vezet, nem pedig csendes továbbengedéshez.

# Biztonságos kezdő- és záróminta:
FILE=$(jq -r '.tool_input.file_path // empty')
[ -z "$FILE" ] && exit 0
# ... az Ön logikája ...
exit 0   # vagy egysoros parancsnál || exit 0

2. buktató. A lassú hookok időkorlát miatt leállnak

Volt egy hookom, amely az Edit után a teljes fájlon lefuttatta az eslint --fix parancsot. A nagy fájlok (1000+ sor) feldolgozása 8–10 másodpercet vett igénybe. A Claude Code alapértelmezett hook-időkorlátja 60 másodperc, ezért azt hittem, beleférek. Ha azonban egy percen belül több Edit történik, a hookok feltorlódnak a sorban, és néhányat egyszerűen kihagy a rendszer. Erre csak akkor jöttem rá, amikor a naplóban megjelent a „hook timed out” üzenet.

Javítás: ha a hooknak komoly munkát kell végeznie, futtassa a háttérben. Használja az eslint --fix "$FILE" & parancsot anélkül, hogy megvárná az eredményt. Így a hook ezredmásodpercek alatt visszatér exit 0-val, miközben a tényleges munka a háttérben folyik.

# Hosszú művelet a háttérben:
npx eslint --fix "$FILE" &
exit 0

3. buktató. A hook nem látja a projekt környezeti változóit

Azt hittem, hogy a hookban a process.env ugyanúgy elérhető, mint egy Node.js-alkalmazásban. Nem így van. A hook a Claude Code szülőfolyamata által indított shellben fut, és csak a ~/.zshrc vagy ~/.bashrc tartalmát, valamint azokat az értékeket látja, amelyeket a Claude Code kifejezetten átad neki. Ha a hooknak a .env fájlban szereplő OPENAI_API_KEY változóra van szüksége, kézzel kell beolvasnia a .env fájlt.

Javítás: olvassa be kifejezetten a .env fájlt a hook parancsában.

# A projektkörnyezet átadása a hooknak:
cd "$PWD" && source .env && curl -H "Authorization: Bearer $OPENAI_API_KEY" ...
# Vagy dotenv használatával:
dotenv -e .env -- node my-validator.js

Ez különösen kellemetlen monorepóban, ahol a csomagok saját .env fájllal rendelkeznek. Oldja meg úgy, hogy átadja a PWD értékét, majd a parancs elején kifejezetten futtatja a cd "$PWD" parancsot.

Hogyan tesztelje a hookokat commit előtt?#

Alapvető teszteset. Vegye ki a hook parancsát a JSON-ból, nyisson meg egy terminált, és adja át neki azt a JSON-t, amelyet a Claude Code küldene:

# Az 1. hook tesztje (.env védelme):
echo '{"tool_input":{"file_path":".env"}}' | bash -c '
FILE=$(jq -r ".tool_input.file_path // empty")
[ -z "$FILE" ] && exit 0
echo "$FILE" | grep -qE "(^|/)\.env(\.|$)" && {
  echo "BLOCKED" >&2
  exit 2
} || exit 0
'
echo "Exit code: $?"

A stderr kimenetében a BLOCKED, az eredményben pedig az Exit code: 2 szöveget kell látnia. Ha 0-s kilépési kódot kap, a regex nem működik; javítsa meg a grep-parancsot.

Ellenőrizendő esetek:

1. Sikeres eset - a fájlt blokkolni kell. Az 1. hooknál .env, a 3. hooknál git push --force main.
2. Negatív eset - a fájlt nem szabad blokkolni. Az 1. hooknál README.md, a 3. hooknál git push origin feature-branch.
3. Szélső esetek - üres bemenet, null értékek, váratlan karakterek. A hook adjon vissza exit 0-t vagy világos hibát, ne engedjen tovább csendben.

Hová tegye a kísérleti hookokat? Ne a .claude/settings.json fájlba, hanem a .claude/settings.local.json fájlba (ne kerüljön gitbe). Az új hookokat a PostToolUse alatt adja hozzá echo paranccsal a tényleges művelet helyett, ellenőrizze, hogy lefutnak-e, majd tegye át őket a produkciós settings.json fájlba.

// Kísérlet a settings.local.json fájlban - naplózás a /tmp/hook-debug.log fájlba:
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"[hook fired] $(date) $(jq -r '.tool_input.file_path // \"?\"')\" >> /tmp/hook-debug.log"
          }
        ]
      }
    ]
  }
}

A Claude Code-ban végzett 5–10 szerkesztés után nyissa meg a /tmp/hook-debug.log fájlt, hogy lássa, mely fájlok váltották ki a hookot. Ha üres, akkor a matcher nem illeszkedik; javítsa meg a regexet.

Mi következik?#

5 lépés a következő hétre:

1. Keressen rá a CLAUDE.md fájlban az olyan szavakra, mint „soha”, „tilos”, „mindig” és „kell”. Minden ilyen szabály hookjelölt. Ha egy szabály felszólító, a szövegfájl nem fogja kikényszeríteni.
2. Kezdje a PostToolUse + exit 0 kombinációval. Ezek a legbiztonságosabbak: módosítanak valamit, de semmit sem blokkolnak. Prettier (2. hook), fejlesztői szerver leállítása (5. hook), automatikus commit a tesztek után (6. hook).
3. Csak akkor adja hozzá az első PreToolUse + exit 2 hookot, ha már biztos benne. Például védje a .env fájlt (1. hook), vagy akadályozza meg a force-push műveletet (3. hook). Ez kemény blokkolás, és a grep-parancs hibája akár Önt is letilthatja.
4. Commit előtt kézzel tesztelje a hookokat (lásd a fenti részt). Ezzel órákig tartó hibakeresést takaríthat meg.
5. A kísérletekhez használja a settings.local.json fájlt. Az új hookokat az éles művelet helyett echo-val adja hozzá.

A hookok beállítása után az útmutatócsoport következő lépése a Claude Code-ban végrehajtott változtatások visszavonása, arra az esetre, ha egy hook átengedne valami veszélyeset. Ha azt szeretné, hogy Claude a munkamenetek között is emlékezzen a projekt struktúrájára, építsen Second Braint a Claude Code-ban (business/ mappa + összekapcsolt tudásbázis). Ha pedig nevet szeretne adni a projekt skilleknek, hogy újra felhasználhatók legyenek, tekintse meg a Claude Code Skills útmutatót.

Ha az Ailooton keresztül szeretne hozzáférni neurális hálózatokhoz, tekintse meg az Ailootot.