Blast Radius in Claude Code: valutare i comandi prima di agire

Blast Radius è una demo di Claude Code Mods che chiede una decisione prima di determinati comandi di shell. Sospende la chiamata, rappresenta cosa potrebbe toccare e permette all’utente di procedere o annullare. L’utilità è rendere l’impatto leggibile nel punto della scelta; la demo non riconosce automaticamente ogni comando pericoloso. README ufficiale Blast Radius.

Questa guida, verificata il 9 ottobre 2026, spiega come valutare il flusso senza provarlo su produzione o attribuirgli una sicurezza assoluta. Gli esempi italiani sono ipotetici. Per capire il meccanismo generale, leggi cosa sono i Mods di Claude; per una regola configurata su un evento, confronta la guida agli Hooks.

Quale decisione dovrebbe rendere più chiara?

La domanda iniziale è «cosa cambierà se autorizzo questa operazione?». L’utente deve capire oggetto, estensione e reversibilità del cambiamento. Un elenco di file può essere utile, ma non basta se manca il rapporto con il task. Un file piccolo può essere essenziale; una cartella grande può contenere soltanto artefatti ricostruibili. Il volume dell’impatto non coincide con il suo valore.

Per una buona decisione servono anche lo stato corrente e l’obiettivo. Un’operazione che elimina modifiche locali ha un significato diverso prima o dopo una review. Una migrazione va collegata all’ambiente e al piano di cambiamento, non letta come una generica manutenzione. La UI può presentare informazioni, mentre il responsabile confronta quelle informazioni con ciò che ha effettivamente autorizzato.

Questo spiega perché una demo interattiva non sostituisce le regole del team. La policy aziendale per l’uso dell’AI dovrebbe stabilire chi può approvare quale categoria di azione. Un collega che sa leggere la schermata potrebbe comunque non avere l’autorità di modificare un sistema condiviso. Mostrare due pulsanti non risolve questa distinzione organizzativa.

Quali categorie di comandi tratta l’esempio ufficiale?

Il README descrive categorie come cancellazioni ricorsive, perdita di modifiche Git, pulizia di file non tracciati, push che riscrivono la storia remota e alcuni strumenti di migrazione. Sono capacità documentate della demo, da leggere insieme alle limitazioni. Il confronto utile non è fra «sicuro» e «pericoloso» in assoluto, ma fra l’operazione riconosciuta e l’informazione che può essere ottenuta prima della scelta.

L’anteprima deve essere interpretata secondo il contratto della categoria. «File non tracciato» non significa «file inutile»; «modifica non committata» non significa «modifica sbagliata». Sono stati tecnici, non decisioni di business. Il valore del mod sta nel mostrarli prima del passaggio, evitando che vengano ignorati dietro un comando compatto.

Per la prova prepara un repository isolato con nomi e contenuti sintetici. Il suo scopo è osservare la scelta, non mettere alla prova la fortuna di un sistema reale. Se vuoi sapere come distribuire il componente dopo una valutazione, segui installazione e aggiornamento dei Mods, conservando la distinzione fra demo locale e componente approvato.

Perché directory e composizione della shell contano?

L’impatto dipende dal luogo in cui un comando opera. Un percorso relativo letto nel repository sbagliato può produrre un’anteprima apparentemente precisa ma irrilevante. Il README spiega che la demo considera alcuni cambi di directory e forme Git con percorso esplicito. Non bisogna estendere questa dichiarazione a ogni composizione possibile senza prove.

Una shell consente sequenze, sostituzioni e strutture che non si riassumono con un prefisso. Un riconoscimento basato soltanto sull’inizio della stringa può mancare operazioni incorporate in forme diverse. La documentazione sui permessi distingue l’analisi delle operazioni dalle scorciatoie basate su testo. Per una policy reale bisogna definire il perimetro tecnico, i casi esclusi e ciò che accade quando il parsing non è affidabile.

Durante la valutazione usa quindi casi progettati prima di aprire il plugin: stessa categoria in directory differenti, percorso con spazi e composizione prevista dal contratto. Non inventare un comando rischioso sul sistema reale per cercare un buco. Una prova sintetica può dimostrare una mancata copertura senza trasformare quella dimostrazione in danno.

Come leggere Procedi e Annulla senza automatizzare l’approvazione?

Il README presenta una decisione esplicita: procedere lascia eseguire il comando, annullare rifiuta la chiamata e comunica un motivo a Claude. Il mod mette l’utente nel passaggio, ma la scelta resta significativa soltanto se la schermata può essere compresa. Un’approvazione ripetuta per abitudine riduce il valore del controllo.

La scelta va collegata anche al task corrente. Se il comando cambia scopo rispetto alla richiesta iniziale, serve una nuova valutazione. Un’anteprima corretta dell’impatto non rende pertinente un’azione che il responsabile non ha chiesto.

Un buon processo prevede un criterio breve: operazione richiesta, ambiente corretto, impatto compatibile e possibilità di recupero. Se uno dei punti non è chiaro, l’utente può annullare e chiedere una proposta più circoscritta. L’annullamento non è un fallimento del progetto; può essere il risultato corretto della valutazione. Deve consentire di proseguire con un’alternativa comprensibile.

La guida agli eventi Mods mostra il principio di una chiamata trattenuta in attesa della scelta. Per trasformarlo in una funzione del team non basta riprodurre il pannello. Devi definire cosa succede in assenza di risposta, quando manca un dato e quando l’interazione viene interrotta.

Cosa succede quando l’anteprima è incompleta?

Una UI onesta deve rendere riconoscibile il dato mancante. Se lo strumento non può elencare le migrazioni pendenti, la schermata non dovrebbe suggerire «nessuna migrazione». Assenza dell’informazione e assenza dell’impatto sono condizioni diverse. Il README distingue strumenti di migrazione supportati e casi per cui non può offrire un elenco.

Il responsabile può scegliere una verifica separata o restringere l’operazione. Il criterio non è «la finestra si è aperta»: è «la decisione può essere presa con informazioni sufficienti». Un numero senza origine o una lista che omette un limite possono creare una fiducia peggiore del semplice messaggio «dato non disponibile».

Una scheda per decidere davanti a un’anteprima incompleta

Identifica quale dato manca e se quel dato cambia la decisione. Controlla ambiente e obiettivo dell’azione. Se l’impatto non è valutabile, annulla e prepara un percorso di verifica separato. Registra la categoria esclusa dal contratto del componente, così il team non la considera coperta nella prova successiva.

Quali requisiti di interfaccia e ambiente verificare?

La demo usa una UI terminale con pannello e un’alternativa nella banda quando lo spazio è insufficiente. Richiede strumenti locali per calcolare alcune anteprime. Il README documenta inoltre rifiuto per timeout o interruzione. Questi requisiti riguardano una versione e una superficie specifiche; non dimostrano un comportamento identico in ogni ambiente Claude Code.

Il controllo iniziale comprende dimensione del terminale, prerequisiti presenti e messaggio in caso di errore. Una funzione che appare su una macchina può essere assente su un’altra per ragioni di layout o caricamento. La diagnosi dei Mods permette di separare queste cause dal risultato del gate. Non cambiare una policy soltanto per correggere un pannello che non viene disegnato.

Per una prova ripetibile prepara i casi positivi e negativi nel medesimo ambiente. Verifica il comportamento quando l’utente annulla, quando il dato non arriva e quando l’interazione termina. La guida a testare un Claude Code Mod distingue la simulazione del flusso dalla prova della resa sulla superficie adottata.

Quale stato deve essere stabile al momento della scelta?

Un’anteprima descrive una rilevazione. Se l’ambiente cambia mentre l’utente valuta, la decisione potrebbe non riferirsi più allo stesso stato. Non affermiamo che la demo ricontrolli automaticamente ogni variazione: è un requisito da verificare quando si progetta un componente aziendale. Il team deve sapere quali condizioni rendono ancora valida la scelta e quando serve rifare la valutazione.

Considera un repository in cui un altro processo scrive file durante l’attesa. Il conteggio iniziale potrebbe non descrivere l’insieme successivo. Oppure considera un piano di migrazione modificato da un collega: l’anteprima letta prima del cambiamento non è una nuova autorizzazione sul piano aggiornato. Questi sono scenari progettati per ragionare sulla consistenza, non risultati osservati nella demo ufficiale.

Una soluzione del team può limitare la finestra della decisione, richiedere una nuova rilevazione o rifiutare quando lo stato non è verificabile. La scelta dipende dalla categoria e dalle conseguenze dell’azione. Scrivila nel contratto e prepara il caso negativo: stato cambiato, informazione precedente riconoscibile e comportamento previsto. Se non puoi dimostrare che la decisione riguarda l’azione effettiva, una UI più dettagliata non risolve il problema. Questa verifica completa la review dell’interazione senza attribuire al prototipo capacità di coordinamento mai provate.

Due scenari ipotetici: manutenzione e migrazione

Esempio ipotetico: una PMI di Modena mantiene una dashboard interna. Il team vuole rendere più leggibili le operazioni sui file non tracciati. Nel repository didattico prepara artefatti ricostruibili e un documento sintetico da preservare. La prova verifica che l’anteprima aiuti a riconoscere la differenza e che annullare impedisca il passaggio previsto dal test.

La review non si limita al conteggio: confronta i percorsi con l’obiettivo della manutenzione. Se il documento importante appare insieme agli artefatti, la proposta va ristretta. Il risultato desiderato è una decisione corretta su quel caso, non una dichiarazione che ogni futura pulizia sarà sicura. La policy continua a vietare azioni non autorizzate e a richiedere un percorso di recupero.

Esempio ipotetico: una software house di Roma valuta una migrazione. Il responsabile usa un ambiente sacrificabile e un dataset sintetico. L’anteprima permette di discutere il passaggio con il collega che conosce il piano. Se lo strumento non offre i dettagli necessari, il gruppo sospende la decisione e consulta il percorso di controllo previsto dal progetto.

La stessa schermata non viene poi adottata come sostituto delle approvazioni di produzione. Per la distribuzione serve un contratto più stretto: ambienti, prerequisiti, responsabilità e comportamento in errore. La guida a Mods per team e sicurezza tratta questa differenza fra personalizzazione utile e policy organizzativa.

Quali errori danno una falsa sensazione di sicurezza?

Il primo è considerare ogni comando non intercettato innocuo. Il secondo è fidarsi di un’anteprima senza controllare la directory. Il terzo è equiparare una quantità piccola a un impatto piccolo. Il quarto è ignorare il dato mancante. Il quinto è trasformare un’approvazione singola in autorizzazione per tutta la sessione.

C’è anche un limite più profondo: il codice di un mod non è sandboxato. Un guard delle tool call non protegge automaticamente ogni accesso diretto del mod a filesystem o processi. La sicurezza dei plugin richiede fiducia e review del componente. La guida a AI e sicurezza dei dati aiuta a distinguere questo confine dai controlli sul processo aziendale.

Non usare inoltre questa demo per dedurre la semantica degli errori dei settings Hooks. Sono meccanismi distinti. La release 2.1.295 introduce onFailure: "block" per command e HTTP Hooks, ma non ne forniamo qui uno schema operativo non verificato. Il fatto è documentato nelle release ufficiali; non prova che la demo copra ogni failure di un altro sistema.

Come decidere se adottare questo tipo di interazione?

Valuta se il team incontra una scelta che l’anteprima può rendere davvero più chiara. Poi scrivi cosa è coperto, cosa resta fuori e chi può approvare. Se i casi non riconosciuti sono proprio quelli più frequenti, forse serve un controllo diverso. Se il problema è soltanto capire il risultato di un turno, potrebbe bastare Replay Theater insieme al diff reale.

Per progettare una decisione assistita coerente con il tuo ambiente, il percorso di software su misura può partire da una categoria di operazioni e da una prova negativa esplicita. Il confronto fra Mods e Hooks aiuta a scegliere il meccanismo con responsabilità e limiti comprensibili al team.