TL;DR: il 5 agosto 2026 un agente di coding ha cancellato la home directory di uno sviluppatore mentre gli era stato chiesto di farne il backup. Da qui due difese possibili: ripristinare dopo (backup, git, snapshot) o contenere prima (confine imposto dal sistema operativo). Non sono alternative, ma se hai tempo per una sola scegli il contenimento — perché il ripristino non riporta indietro le credenziali, e perché l’agente che sbaglia un path può cancellare anche il backup.

Il fatto, in tre righe

Su r/ClaudeCode un utente ha raccontato di aver chiesto a Claude Opus 5 di creare un backup del sistema. L’agente ha scritto il backup nella directory sbagliata, ha creduto di dover ripulire il proprio errore e ha lanciato rm -rf su quello che pensava fosse la copia temporanea: era la cartella profilo. Il path in gioco era /c/Users/harih/: secondo la ricostruzione di Tom’s Hardware, la forma che una shell Unix-like assume su Windows al posto di C:\Users\harih\. Alla fine l’agente ha risposto «Sorry, typo».

Non è un caso isolato: nel 2025 la stessa dinamica ha colpito un database di produzione durante un code freeze (il caso Replit, a luglio) e il disco secondario di un utente a cui era stato chiesto solo di svuotare una cache (l’agente Google Antigravity, a novembre). Il punto è che l’operazione pensata come rete di sicurezza è stata quella che ha causato la perdita.

Il criterio: cosa accade nell’istante in cui l’agente sbaglia il path

Una discussione su «agenti sicuri» diventa concreta solo con un criterio. Il mio: nel momento in cui il modello ha ragionato male e sta per eseguire una scrittura distruttiva, chi lo ferma? Due risposte strutturalmente diverse, e non si scelgono per gusto.

Ripristino: il comando parte, il danno è reale, e la difesa entra in gioco dopo. Si misura in tempo di ripristino e in quanto materiale era versionato.

Contenimento: la syscall viene negata dal sistema operativo, il comando fallisce, il danno non avviene. Si misura in attrito quotidiano e in tempo di setup.

Opzione A — ripristinare: veloce da adottare, cieca su metà del disco

È l’approccio implicito di quasi tutti: permessi ampi all’agente, e git, Time Machine o gli snapshot del filesystem come paracadute. I vantaggi sono reali: zero attrito, l’agente lavora alla sua velocità, e funziona su qualunque OS e qualunque stack.

Il limite è che copre solo ciò che è versionato o già copiato altrove. Nella home di chi fa manutenzione siti non c’è solo codice: ci sono i file .env, le chiavi in ~/.ssh, le sessioni FTP salvate, i database dump dei clienti, i token dei connettori. Roba che per definizione non sta su git — e che è giusto tenere fuori dal repository. Un ripristino da git ti restituisce il progetto e ti lascia senza le credenziali per rimetterlo online.

C’è poi il problema che rende l’episodio istruttivo: se il backup è raggiungibile in scrittura dal processo dell’agente — un disco montato, una cartella sincronizzata, un NAS con la share aperta — non è una difesa, è un’altra cosa da cancellare. Un backup vale come difesa solo se la destinazione tira i dati (pull) invece di riceverli, o se l’agente non ha il permesso di scrivere lì.

Opzione B — contenere: il confine non discute con il modello

L’alternativa è togliere all’agente la possibilità fisica di toccare ciò che non riguarda il task. Claude Code lo fa con un Bash sandbox costruito sulle primitive del sistema: Seatbelt su macOS, bubblewrap su Linux e WSL2. Il confine di default: i comandi possono scrivere solo nella working directory e nella cartella temporanea di sessione, e vale per ogni comando Bash e per i suoi processi figli. Per mettere anche tool interni, MCP server e hook dentro lo stesso confine c’è @anthropic-ai/sandbox-runtime, dichiarato beta research preview, che avvolge l’intero processo e per default nega perfino la rete.

Il costo c’è: setup iniziale, prompt quando un comando serve fuori dal confine, e un dettaglio che qui pesa più di tutti — il Bash sandbox non supporta Windows nativo. Su Windows la strada documentata è WSL2, un container o una VM. E il prefisso /c/ è la forma di Git Bash e MSYS2, non di WSL2, che monta i dischi sotto /mnt/c/: se la ricostruzione è corretta, l’incidente è avvenuto proprio nella configurazione in cui il confine imposto dall’OS non è disponibile.

Il contenimento non è magia: riduce l’impatto, non azzera il rischio. Se la rete resta aperta l’agente può esfiltrare ciò che legge, se il progetto è montato in scrittura può rovinare quel codice, e nessun confine cambia ciò che viene mandato al modello.

Perché preferisco il contenimento, tecnicamente

Sul lato del riconoscimento esistono guardrail veri: anche con --dangerously-skip-permissions le rimozioni che puntano a / o alla home continuano a chiedere conferma, e il classificatore della modalità auto valuta esplicitamente i rm -rf / e rm -rf ~, anche quando la rimozione è annidata in una command substitution.

Ma è una difesa che dipende dal riconoscimento: regola o classificatore, qualcuno deve capire che quel path è la home. La documentazione parla di ~ e /, non di una home raggiunta come /c/Users/harih/, e nessuna fonte dice quale configurazione fosse attiva in questo caso. Un confine del sistema operativo non deve capire niente: sa quali inode sono scrivibili, e quel giudizio non peggiora quando il modello si confonde.

Cosa fare, concretamente

Se gestisci siti di clienti dalla tua macchina, tre cose valgono più di qualunque policy scritta.

La prima: fai girare l’agente con la working directory sul repository del sito, non sulla home — il default della sandbox serve solo se coincide con il perimetro del lavoro. La seconda: su Windows, WSL2 o container, perché altrimenti stai usando il livello di permessi senza il livello di isolamento. La terza: i backup dei clienti non devono essere scrivibili dal processo che fa il lavoro — destinazione pull, o credenziali che l’agente non ha.

E prima di tutto questo vale la regola più noiosa: iniziare dalle automazioni in sola lettura e dare la scrittura solo quando il perimetro è chiuso. La stessa logica che applico quando scelgo tra un agente e uno script deterministico: se il compito è ripetibile, non serve un agente che possa improvvisare.

La take

Il backup non è una difesa contro un agente: è una difesa contro un guasto. Un guasto non ti segue nella cartella dove hai messo la copia, un agente con i permessi sbagliati sì. Chi tiene i permessi ampi perché «tanto c’è il backup» sta usando lo strumento giusto contro la minaccia sbagliata, e lo scopre nel momento peggiore — quando deve ricostruire le credenziali di un cliente da zero, di venerdì.

Il confine prima, il ripristino dopo. In quest’ordine, perché il ripristino è l’unica delle due che ammette di aver già perso.

Fonti