Hooks di Claude Code: 5 automazioni che cambiano il workflow

Tra le funzioni meno discusse di Claude Code ci sono gli hooks: comandi shell che vengono eseguiti automaticamente quando si verificano certi eventi durante una sessione. Sono potenti e mediamente sottoutilizzati. Ecco 5 hooks concreti che ho impostato e che cambiano in modo sostanziale il lavoro quotidiano.

Cosa sono gli hooks, in 30 secondi

Gli hooks si configurano in ~/.claude/settings.json dentro la sezione hooks. Si associano a eventi (PreToolUse, PostToolUse, SessionStart, SessionStop, Stop) e contengono uno script shell. Quando l’evento scatta, lo script viene eseguito automaticamente — senza che il modello debba “ricordarsi” di farlo.

L’idea chiave: lo prevede l’harness (l’ambiente Claude Code), non l’AI. Quindi e affidabile in modo diverso dal chiedere al modello “ricordati di fare X”. Si esegue garantito.

Hook 1 — Notifica desktop quando una sessione finisce

Capita di lanciare un task lungo (refactor multi-file, build di test) e poi cambiare finestra. Senza notifica si scopre che e finito solo controllando manualmente. Con un hook su Stop:

{
  "hooks": {
    "Stop": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "powershell -Command \"New-BurntToastNotification -Text 'Claude ha finito'\""
      }]
    }]
  }
}

Su Windows serve il modulo PowerShell BurntToast. Su Mac il comando equivalente e osascript -e 'display notification ...'.

Hook 2 — Backup automatico prima di modifiche bulk

Quando Claude sta per usare un tool di editing su molti file (esempio: MultiEdit o Write ripetuti), pre-creare un backup salva da incidenti. Hook su PreToolUse:

{
  "PreToolUse": [{
    "matcher": "Write|Edit|MultiEdit",
    "hooks": [{
      "type": "command",
      "command": "git stash push -m 'pre-claude-edit' --quiet || true"
    }]
  }]
}

L’effetto: prima di ogni Write/Edit, lo stato corrente del repo viene messo in stash. Se il risultato non e quello atteso, un git stash pop ripristina tutto.

Hook 3 — Format automatico dopo modifiche

Tipica seccatura: il modello modifica codice e l’indentazione non e perfetta. Hook su PostToolUse che esegue il formatter del linguaggio:

{
  "PostToolUse": [{
    "matcher": "Edit|Write",
    "hooks": [{
      "type": "command",
      "command": "if [ \"${TOOL_INPUT_file_path##*.}\" = \"py\" ]; then black \"$TOOL_INPUT_file_path\"; fi"
    }]
  }]
}

Funziona con qualsiasi formatter — Prettier per JS/TS, Black per Python, gofmt per Go, rustfmt per Rust. Il pattern e identico: dopo che Claude tocca un file, lancia il formatter.

Hook 4 — Test runner dopo refactor

Per progetti con test suite veloce, lanciare i test dopo ogni edit ti da feedback immediato se qualcosa si e rotto. Hook:

{
  "PostToolUse": [{
    "matcher": "Edit|Write|MultiEdit",
    "hooks": [{
      "type": "command",
      "command": "cd $CLAUDE_PROJECT_DIR && npm test -- --silent 2>&1 | tail -5"
    }]
  }]
}

Attenzione: usare solo se i test sono veloci (sotto i 30 secondi). Altrimenti rallentano in modo insopportabile l’esperienza interattiva.

Hook 5 — Log di sessione per audit

Per chi lavora in contesti dove serve tracciabilita (regolamentazione, audit, lavoro su sistemi sensibili), un hook su SessionStart e SessionStop che logga inizio e fine in un file:

{
  "SessionStart": [{
    "matcher": "*",
    "hooks": [{
      "type": "command",
      "command": "echo \"[$(date -Iseconds)] Session START in $CLAUDE_PROJECT_DIR\" >> ~/.claude/session.log"
    }]
  }],
  "SessionStop": [{
    "matcher": "*",
    "hooks": [{
      "type": "command",
      "command": "echo \"[$(date -Iseconds)] Session STOP\" >> ~/.claude/session.log"
    }]
  }]
}

Il log resta sul tuo disco, non viaggia. Utile per giustificare attivita ex-post.

Cosa NON fare con gli hooks

Tre antipattern da evitare:

• Hooks lenti. Tutto cio che esegui pre/post tool blocca la sessione. Se l’hook dura piu di 1-2 secondi, l’esperienza diventa frustrante.
• Hooks distruttivi. Un hook su PostToolUse che cancella o sovrascrive file e fragile: se Claude faceva qualcosa di diverso da quanto presupposto, perdi dati.
• Hooks che assumono un contesto specifico. Se il tuo hook funziona solo dentro un certo progetto, va messo nel settings.local.json di progetto, non in quello globale.

Gli hooks sono come i pre-commit di git: silenziosi quando funzionano, frustranti quando si rompono. Iniziare con 1-2 hooks semplici e affidabili e meglio che configurarne 10 e dover poi disabilitarli quando rallentano.

Fausto Pitzalis

Blogger dal 2001, Nativo Digitale, Developer.
Da 15 anni mi occupo di IT per una grande Azienda.
Lavoro per abbattere il Digital Divide.
Visita i miei altri progetti
sardiniamobility.com
www.cyberness.it