Cosa sono OpenClaw Hooks? (E perché cambiano il modo in cui lavori con gli agenti IA)
Se hai mai visto un agente AI sovrascrivere un file che non dovrebbe toccare o hai desiderato che eseguisse automaticamente la tua suite di test dopo ogni modifica del codice, gli hook OpenClaw sono la risposta. Ti consentono di intercettare, reagire e controllare il comportamento degli agenti proprio nei momenti che contano.
Hooks sono piccoli script guidati da eventi eseguiti all'interno del gateway OpenClaw in punti specifici del ciclo di vita di un agente. Considerali come un middleware per il tuo agente AI: si collocano tra l'agente e gli strumenti che chiama, offrendoti un livello di intercettazione programmabile.
Ne esistono due tipologie distinte:
- Internal hooks — script che vengono eseguiti dentro il processo Gateway stesso. Hanno accesso diretto allo stato della sessione, ai metadati delle chiamate allo strumento e al contesto lavorativo dell'agente. Zero sovraccarico di rete.
- Webhooks — Callback HTTP attivati su un endpoint esterno quando si verifica un evento del ciclo di vita. Il Gateway invia una richiesta POST; il tuo server gestisce la logica.
La differenza pratica: i ganci interni sono per guardrail veloci e sincroni e automazione locale. Webhooks sono per tutto ciò che deve raggiungere l'esterno della tua macchina: notifiche Slack, sistemi CI, piattaforme di registrazione.
Internal Hooks vs. Webhooks: quale ti serve?
| Fattore | Gancio interno | Webhook |
|---|---|---|
| Execution location | Inside the Gateway process | External HTTP server |
| Latency | Near-zero (synchronous) | Network round-trip |
| Session state access | Direct | Serialized payload only |
| Meglio per | File guards, auto-formatting, local scripts | Slack alerts, audit logging, external APIs |
| Complessità di installazione | Low: solo una directory + file del gestore | Medium: richiede un endpoint HTTP in esecuzione |
| Blocking agent execution | Yes (PreToolUse hooks can abort) | Typically async/non-blocking |
Decision rule: Se il tuo gancio ne ha bisogno impedire un'azione o leggere i dati della sessione locale, utilizzare un gancio interno. Se è necessario notificare un sistema esterno e non è necessario bloccare l'agente, utilizza un webhook.
Come funziona la scoperta degli hook OpenClaw
Il Gateway utilizza scansione automatica delle directory per scoprire i ganci. All'avvio, esegue la scansione delle directory di hook configurate e carica tutti i pacchetti di hook validi che trova.
Due prerequisiti importanti prima dell'attivazione degli hook:
- Hooks deve essere abilitato esplicitamente — una directory hook da sola non è sufficiente
- Almeno è necessario configurare una voce hook nelle impostazioni del tuo Gateway
Questo è un punto di confusione comune. Puoi avere un hook scritto perfettamente nella directory giusta, ma se al Gateway non è stato detto di attivare gli hook, li ignora silenziosamente.
Ogni pacchetto hook richiede esattamente due file:
HOOK.md— file di metadati che dichiara il nome dell'hook, la versione, la descrizione, le sottoscrizioni agli eventi del ciclo di vita e tutte le autorizzazioni richiestehandler.ts(ohandler.js) — il file di implementazione contenente la logica effettiva che viene eseguita quando si attiva l'evento
Il file HOOK.md è ciò che il Gateway legge per primo durante il rilevamento. Se il formato è errato o mancano i campi obbligatori, l'hook non verrà caricato: nessun errore, solo silenzio. Questa è la causa più comune delle segnalazioni "il mio hook non funziona".
I quattro eventi del ciclo di vita che ogni sviluppatore dovrebbe conoscere
| Evento | Quando spara | Uso comune |
|---|---|---|
| PreToolUse | Prima l'agente chiama qualsiasi strumento | Block dangerous operations, validate inputs |
| PostToolUse | Dopo viene completata una chiamata allo strumento | Codice formato Run tests,, risultati del registro |
| Stop | Al termine della sessione dell'agente | Send notifications, flush logs, cleanup |
| SessionStart | Quando inizia una nuova sessione dell'agente | Load context, set guardrails, warm up state |
PreToolUse è il più potente: è l'unico evento che può farlo interrompere una chiamata allo strumento prima che venga eseguita. Se il tuo hook restituisce un segnale di rifiuto durante PreToolUse, l'agente non chiamerà mai lo strumento.
PostToolUse è il cavallo di battaglia per l'automazione. File scritto? Esegui il tuo linter. Prova modificata? Esegui la suite. Codice impegnato? Attiva una build.
Step-by-Step: scrivere il tuo primo hook personalizzato da zero
La maggior parte della documentazione mostra i comandi. Questo ti mostra il percorso completo dal nulla a un hook funzionante.
Goal: Esegui automaticamente ESLint dopo ogni scrittura di file.
Step 1: crea la directory hook
mkdir -p .openclaw/hooks/auto-lint
Step 2: scrive i metadati HOOK.md
# auto-lint
**Version:** 1.0.0
**Event:** PostToolUse
**Description:** Runs ESLint on any file written by the agent
**Tools:** write_file, edit_file
Il campo Tools definisce l'ambito del tuo hook per chiamate di strumenti specifici. Senza di esso, il gancio si accende ogni Evento PostToolUse: di solito non è quello che desideri.
Step 3: implementazione handler.ts
import { PostToolUseEvent } from "@openclaw/sdk";
import { execSync } from "child_process";
export default function handler(event: PostToolUseEvent) {
const filePath = event.toolResult?.path;
if (!filePath) return;
try {
execSync(`npx eslint --fix "${filePath}"`, { stdio: "inherit" });
} catch (err) {
console.error(`[auto-lint] ESLint failed on ${filePath}`);
}
}
Step 4: abilita tramite CLI
openclaw hooks enable auto-lint
Step 5: verifica che sia caricato
openclaw hooks list
Dovresti vedere auto-lint con lo stato enabled. Avvia una sessione, scrivi un file e osserva il fuoco del linter.
JavaScript vs. TypeScript per gestori di ganci: cosa scegliere nel 2026
L'SDK viene fornito con digitazioni TypeScript complete e, a partire dalle versioni dell'SDK del 2026, TypeScript è l'impostazione predefinita consigliata per nuovi ganci.
| Fattore | TypeScript | JavaScript |
|---|---|---|
| Type safety | Full: le forme degli eventi vengono digitate | None: sorprese in termini di runtime |
| Compilation step | Required (tsc or esbuild) | None |
| SDK compatibility | First-class support | Supported but no autocomplete |
| Meglio per | Any hook that will be maintained or shared | Script rapidi e unici |
Se stai scrivendo un hook che ti impegnerai nel controllo della versione o che condividerai con un team, usa TypeScript. Per un guardrail locale usa e getta, il semplice JavaScript va bene: chiamalo semplicemente handler.js e salta il passaggio di compilazione.
OpenClaw Hooks CLI Reference
| Comando | Flags | Cosa fa |
|---|---|---|
| elenco degli ami openclaw | --json |
Lists all discovered hooks and their status |
| gli hook openclaw ispezionano |
— | Mostra i metadati completi da HOOK.md + configurazione corrente |
| Gli hook openclaw abilitano |
— | Activates a hook per il progetto corrente |
| Gli hook openclaw disabilitano |
— | Deactivates without removing |
| i ganci openclaw installano |
__CE_BLOCCO_18__, __CE_BLOCCO_19__ | Installs a hook pack from registry |
| Aggiornamento dei ganci openclaw | __CE_BLOCCO_20__, __CE_BLOCCO_21__ | Updates installed hook packs |
Managing Hook Packs: installazione, aggiornamento e flusso di lavoro --dry-run
I pacchetti di ganci raggruppano più ganci correlati come un'unica unità installabile. Il flusso di lavoro di installazione verifica un file hash di integrità prima di scrivere qualsiasi cosa sul disco.
__EC_BLOCCO_23__Il flag --dry-run è sottoutilizzato. Eseguilo prima di qualsiasi install o update per vedere esattamente quali file cambierebbero. Nelle pipeline CI, associare --yes con --dry-run in un passaggio di convalida separato prima dell'installazione reale.
Bundled Hooks Reference: cosa viene fornito con OpenClaw
| Gancio | Stato predefinito | Cosa fa | Meglio usato quando |
|---|---|---|---|
| memoria di sessione | Enabled | Persists key context across sessions | Long-running projects with recurring tasks |
| additional bundled hooks vary by Gateway version | — | Esegui openclaw hooks list --builtin per vedere il tuo |
— |
Esegui openclaw hooks inspect session-memory per vedere le sue opzioni di configurazione complete. La maggior parte degli hook in bundle vengono forniti con impostazioni predefinite ragionevoli ma espongono campi di configurazione per la personalizzazione.
Casi d'uso degli hook nel mondo reale (con esempi funzionanti)
1. File Protection Guardrail (PreToolUse)
Impedisci all'agente di toccare il tuo file .env:
import { PreToolUseEvent } from "@openclaw/sdk";
export default function handler(event: PreToolUseEvent) {
const target = event.toolInput?.path ?? "";
if (target.includes(".env")) {
return { abort: true, reason: "Modification of .env files is blocked by policy." };
}
}
Rilascialo in .openclaw/hooks/protect-env/ con la sottoscrizione HOOK.md corrispondente a PreToolUse con ambito write_file e edit_file. L'agente riceve il motivo del rifiuto nel relativo contesto e non riproverà.
2. Slack Notification on Session Stop
import { StopEvent } from "@openclaw/sdk";
export default async function handler(event: StopEvent) {
await fetch(process.env.SLACK_WEBHOOK_URL!, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
text: `OpenClaw session ended. Files modified: ${event.session.filesModified ?? 0}`
})
});
}
Sottoscrivi questo hook all'evento Stop. Ogni fine sessione genera un messaggio Slack con un riepilogo. Non è necessario alcun server esterno: il processo Gateway effettua direttamente la richiesta in uscita.
3. Auto-Format + Test on PostToolUse
import { PostToolUseEvent } from "@openclaw/sdk";
import { execSync } from "child_process";
export default function handler(event: PostToolUseEvent) {
const file = event.toolResult?.path;
if (!file?.endsWith(".ts")) return;
execSync(`prettier --write "${file}"`);
execSync("npm test -- --passWithNoTests", { stdio: "inherit" });
}
Questo si attiva dopo ogni scrittura del file TypeScript, lo formatta, quindi esegue la suite di test. Lento nei progetti di grandi dimensioni: adattalo strettamente utilizzando il campo Tools in HOOK.md.
Hooks for Teams: applicazione dei guardrail in un progetto condiviso
Affida la tua directory .openclaw/hooks/ al controllo della versione. Ogni sviluppatore che clona il repository ha automaticamente la stessa configurazione di hook.
- Blocca gli hook critici su
enablednella configurazione del progetto - impedisce ai compagni di squadra di disabilitare accidentalmente le protezioni dei file - Utilizza le descrizioni
HOOK.mdper documentare l'intento - trattali come commenti in codice, i compagni di squadra li leggeranno - Scope hooks to tool-level granularity - Gli hook ampi rallentano tutte le interazioni degli agenti, creando attriti che inducono i compagni di squadra a disabilitarli
- In monorepos, gli hook in una directory padre si applicano a tutti i progetti annidati a meno che non vengano sovrascritti a livello di sottodirectory
CI/CD Integration — Esecuzione di OpenClaw Hooks in modo non interattivo
Nelle azioni GitHub o in qualsiasi ambiente headless, la richiesta di conferma interattiva bloccherà la pipeline. Utilizza --yes per saltarlo:
- name: Install hooks non-interactively
run: openclaw hooks install qa-pack --yes
- name: Run OpenClaw session
env:
OPENCLAW_HOOKS_ENABLED: "true"
SLACK_WEBHOOK_URL: secrets.SLACK_WEBHOOK_URL
run: openclaw run --task "audit dependencies" --yes
Imposta OPENCLAW_HOOKS_ENABLED=true come variabile di ambiente per attivare gli hook senza conferma interattiva. Ciò sovrascrive il requisito "almeno una voce configurata" in modalità CI.
Hook Security: cosa funziona, a cosa può accedere e come rimanere al sicuro
Questa è la parte che la maggior parte della documentazione salta completamente ed è la sezione più importante se stai installando hook pack della comunità.
A quali hook può accedere: Gli script hook ereditano il file autorizzazioni complete del processo Gateway. Se il Gateway viene eseguito come account utente, i tuoi hook possono leggere qualsiasi file che l'account può leggere, effettuare richieste di rete, eseguire sottoprocessi e accedere alle variabili di ambiente inclusi i segreti.
Il rischio di pacchetti hook non esaminati: Un hook pack dannoso potrebbe esfiltrare il tuo .env, le tue chiavi SSH o i tuoi token API, il tutto mentre sembra fare qualcosa di benigno come "formattare il codice".
Hook Pack Audit Checklist
Eseguilo prima di installare qualsiasi pacchetto di terze parti:
- ☐Leggi l'intero
HOOK.md: le autorizzazioni dichiarate corrispondono allo scopo dichiarato? - ☐Leggi ogni riga di
handler.ts/js: cerca l'accessofetch(),execSync,process.env - ☐Controlla la provenienza di npm se il pacchetto è distribuito nel registro (
npm info <pack> --json | grep provenance) - ☐Verifica l'identità dell'editore: si tratta di un manutentore noto o di un nuovo account?
- ☐Esegui prima
--dry-runed esamina il file manifest - ☐Non installare mai i pacchetti di hook con
--yessenza prima completare i passaggi precedenti
Il comando openclaw hooks inspect mostra il percorso sorgente completo di un hook installato: utilizzalo per rivedere il codice del gestore dopo gli aggiornamenti.
Troubleshooting OpenClaw Hooks — Quando non sparano
Hook not discovered at all
- Verifica che la directory sia all'interno di un percorso hook scansionato:
openclaw hooks list --verbose - Conferma che
HOOK.mdesiste ed è valido: i campi obbligatori mancanti saltano silenziosamente l'hook - Verifica che gli hook siano abilitati a livello globale e che almeno una voce sia configurata
Hook discovered but not firing
- Esegui
openclaw hooks inspect <name>: verifica che il campoEventinHOOK.mdcorrisponda all'evento del ciclo di vita previsto - Controlla l'ambito
Tools: se hai limitato l'ambito awrite_filema l'agente sta chiamandocreate_file, l'hook non si attiverà - Conferma che lo stato del hook mostra
enabled, nonloaded(caricato significa scoperto ma non attivo)
Hook fires but handler errors are silent
- Aggiungi blocchi
try/catchespliciti conconsole.erroraccedendo al tuo gestore - I registri del gateway vengono scritti in
~/.openclaw/logs/: controlla il registro della sessione più recente per le righe con prefisso[hook] - Utilizzare
openclaw hooks inspect <name> --logsper far emergere l'ultimo output di esecuzione
Hook slowing down every agent action
- Profilo con
openclaw hooks list --timingper vedere il tempo di esecuzione per hook - Sposta le chiamate
execSyncsincrone su asincrone dove il risultato non deve necessariamente bloccare l'agente - L'ambito si aggancia a strumenti specifici anziché iscriversi a tutti gli eventi
PostToolUse
Porta ulteriormente il flusso di lavoro dell'agente AI con EasyClaw
Gli hook OpenClaw ti danno il controllo a livello di agente. EasyClaw ti offre questo controllo, oltre a un ambiente desktop nativo completo creato per sviluppatori e team di contenuti che necessitano di affidabilità, privacy e velocità senza dipendenza dal cloud.
- ✓ Esegui hook, agenti e automazione interamente sul tuo computer: nessun dato lascia il tuo ambiente
- ✓ Integrazione nativa con la tua toolchain di sviluppo esistente: linter, test runner, formattatori, pipeline CI
- ✓ Gestione visiva degli hook: abilita, disabilita e controlla gli hook senza memorizzare i flag della CLI
- ✓ Predisposto per Team: condividi configurazioni di hook, blocchi di guardrail e registri di sessioni di controllo da un'unica dashboard
Frequently Asked Questions
D: Un hook può impedire completamente all'agente di eseguire una chiamata allo strumento?
R: Sì, solo gli hook PreToolUse possono interrompere una chiamata allo strumento. Restituisci { abort: true, reason: "..." } dal tuo gestore e il gateway impedisce l'esecuzione dello strumento. L'agente riceve la stringa del motivo nel suo contesto. Gli hook PostToolUse, Stop e SessionStart non possono interrompere le azioni retroattivamente.
D: Cosa succede se il mio gestore di hook genera un errore non gestito?
R: Per impostazione predefinita, un errore non gestito in un gestore di hook viene registrato nel registro della sessione del gateway ma non provoca l'arresto anomalo della sessione dell'agente. L'agente continua come se il gancio non avesse funzionato. Questo è previsto dalla progettazione: gli hook non dovrebbero mai bloccare la funzionalità principale dell'agente. Racchiudi sempre la logica del gestore in try/catch e gestisci gli errori in modo esplicito in modo da avere visibilità sugli errori.
D: Posso utilizzare async/await nei gestori di hook?
R: Sì, entrambi i gestori PreToolUse e PostToolUse supportano le funzioni asincrone. Per PreToolUse, il gateway attende il gestore prima di decidere se procedere, quindi la logica di interruzione asincrona funziona correttamente. Tieni presente che le operazioni asincrone a esecuzione prolungata in PreToolUse ritarderanno ogni chiamata allo strumento, quindi mantienile veloci.
D: Gli hook si applicano a tutti i progetti o solo a quello in cui si trovano?
R: Gli Hooks inseriti nella directory .openclaw/hooks/ di un progetto hanno un ambito di progetto e si attivano solo per le sessioni in quel progetto. Gli hook globali possono essere posizionati in ~/.openclaw/hooks/ e applicati a tutti i progetti. In monorepos, gli hook in una directory padre si applicano ai progetti nidificati a meno che non vengano sovrascritti a livello di sottodirectory.
D: L'esecuzione di molti hook comporta un costo in termini di prestazioni?
R: Ogni hook aggiunge latenza all'evento a cui si iscrive. Un hook veloce e ben mirato (sotto i 50 ms) è impercettibile. I problemi sorgono quando gli hook eseguono operazioni sincrone pesanti su ogni evento PostToolUse senza ambito a livello di strumento. Utilizza openclaw hooks list --timing per profilare, agganciare l'ambito a strumenti specifici in HOOK.md e spostare il lavoro non bloccante in asincrono ove possibile.
D: Gli hook possono accedere in modo sicuro ai segreti dalle variabili di ambiente?
R: Hooks eredita l'intero ambiente del processo Gateway, quindi process.env.MY_SECRET funziona all'interno di qualsiasi gestore. Per gli ambienti CI, inserisci i segreti tramite il gestore dei segreti della pipeline (ad esempio, i segreti delle azioni GitHub) anziché codificarli manualmente. Non impegnare mai i segreti in HOOK.md o nei file del gestore: considera i file sorgente hook come codice che verrà rivisto e controllato dalla versione.
Considerazioni finali: scegliere la strategia di hook giusta per il flusso di lavoro
| Scenario | Approccio consigliato |
|---|---|
| Solo dev: protegge i file sensibili | Hook interno, PreToolUse, con ambito per scrivere strumenti |
| Solo dev: test ad esecuzione automatica | Hook interno, PostToolUse, con ambito ai tipi di file adiacenti al test |
| Team: applica guardrail condivisi | Applica gli hook al controllo della versione, blocca gli hook critici abilitati nella configurazione del progetto |
| Team: traccia di controllo | Inserimento dell'hook evento Stop su un endpoint di registrazione condiviso |
| CI pipeline: sessioni automatizzate | --yes flag + OPENCLAW_HOOKS_ENABLED env var, --dry-run nella fase di convalida |
| External notifications | Webhook o hook evento Stop con fetch() a Slack/PagerDuty |
Inizia con un hook che risolve un vero problema: una protezione file o un linter post-scrittura. Fallo funzionare end-to-end prima di stratificare di più. La potenza degli hook è composta: una sessione con tre hook con un buon ambito che funziona senza intoppi è significativamente più affidabile di una con dieci hook con un ambito scarso di cui non ti fidi.
Il primo hook con la massima leva per la maggior parte degli sviluppatori: una guardia PreToolUse sul tuo .env e sui file segreti. Richiede dieci minuti per la scrittura, nessuna manutenzione per l'esecuzione ed elimina in modo permanente un'intera classe di errori dell'agente.