Fuga di credenziali in Claude Code con “Yes, and don’t ask again”

Il 5 novembre i ricercatori di Apiiro Shmulik Cohen e Matan Giladi hanno pubblicato un report su una fuga di credenziali da Claude Code verso GitHub. In 104.185 copie pubbliche del file .claude/settings.local.json hanno trovato 1.122 file con almeno un segreto, per un totale di 1.379 password, chiavi API e token diversi.

Come funziona la fuga di credenziali di Claude Code?

Quando Claude Code chiede il permesso di eseguire un comando nel terminale, possiamo scegliere “Yes, and don’t ask again”. Secondo la documentazione di Claude Code, questo consenso viene salvato come regola allow nel file .claude/settings.local.json del progetto.

Il problema è che la regola salva l’intero comando approvato, con tutto quello che ci abbiamo scritto dentro. Se il comando conteneva una password, per esempio PGPASSWORD=… psql … oppure un curl con una chiave API nell’header, quella password finisce nel file in chiaro.

La cosa curiosa è che non si tratta di una scoperta nuova. Ad agosto 2025 qualcuno ha segnalato esattamente questo problema nella issue #5544 (con esempi di chiavi API e token di Jira). Un bot l’ha chiusa il 3 gennaio 2026, dopo 60 giorni di inattività, come “not planned”, senza alcuna correzione.

Se il file è locale, come è finito su GitHub?

In teoria il file è privato. La prima volta che lo scrive, Claude Code aggiunge **/.claude/settings.local.json al file globale di esclusioni di git, così da tenerlo fuori dai commit (è quanto descrive la documentazione).

Questa protezione però ha qualche buco:

1. L’esclusione globale funziona solo su un computer e non viaggia insieme al repository.
2. Se il file l’abbiamo creato a mano, Claude Code non lo esclude e dobbiamo aggiungerlo noi al .gitignore.
3. Le regole di ignore non valgono per i file che git traccia già, quindi un file committato una volta continua a entrare nei commit successivi.
4. Eliminare il file dal repository non lo rimuove né dalla cronologia né dai fork.

Secondo iTWire, in 539 dei 1.105 repository analizzati il file era stato modificato da commit con Claude come coautore.

Quanto è grande il problema?

I numeri del report (dati raccolti dal GitHub pubblico tra l’1 e il 3 novembre):

1. 104.185 copie pubbliche di settings.local.json, di cui 1.122 (circa l’1,1%) contenevano almeno un segreto.
2. In questi file c’erano 1.379 valori diversi.
3. Aggiungendo la cronologia di git, il file condiviso .claude/settings.json e le conversazioni salvate con l’agente, si arriva a 2.539 segreti in 1.994 repository.
4. Apiiro ha avvisato le aziende il 2 e il 3 novembre, e una di loro ha confermato che la chiave esposta era attiva.

Una precisazione: Apiiro non ha verificato se le credenziali trovate funzionassero. Ha scremato i candidati con filtri contro i falsi positivi e la valutazione di un modello linguistico, quindi una parte poteva essere già scaduta.

Perché se ne parla così tanto?

Sabato sera il report è arrivato in prima pagina su Hacker News. L’opzione “don’t ask again” serve a evitare che l’agente chieda continuamente la stessa cosa, quindi è facile dimenticare che cosa sia stato davvero salvato.

È anche l’ennesimo esempio di come oggi i segreti trapelino non solo dal codice delle applicazioni, ma anche dai file di configurazione degli agenti (come nel caso della violazione di OpenCode). Per ora, negli articoli dei media non c’è una risposta di Anthropic.

A cosa fare attenzione in futuro?

1. Prima revochiamo e sostituiamo ogni password o chiave che sia mai finita in questo file in un repository pubblico. Solo dopo ripuliamo la cronologia.
2. Controlliamo se il file è tracciato: git ls-files .claude. Se lo è, smettiamo di tracciarlo (git rm --cached .claude/settings.local.json) e aggiungiamolo al .gitignore del repository stesso, non solo a quello globale.
3. Controlliamo anche la cronologia (git log --all -- .claude/settings.local.json), il .claude/settings.json condiviso e le conversazioni salvate con l’agente.
4. Non scriviamo le password direttamente nei comandi. Meglio passarle tramite variabili d’ambiente o un gestore di segreti e, nelle regole allow, usare pattern come Bash(npm run test *) della documentazione.

Spiego meglio come tenere le chiavi API lontane dagli agenti nella guida sulla sicurezza degli agenti AI, e le basi dello strumento sono nella guida a Claude Code.

FAQ

Claude Code invia da solo le mie password su GitHub?

No. Il file settings.local.json resta sul nostro disco. La fuga avviene solo quando il file finisce in un commit e in un repository pubblico.

Come controllo se il mio settings.local.json è nel repository?

Basta lanciare git ls-files .claude nella cartella del progetto. Se nell’elenco compare settings.local.json, git lo sta tracciando. Vale anche la pena aprire il file e cercare password, token e chiavi nelle regole allow.

Basta eliminare il file dal repository?

No. Il file resta nella cronologia di git e nei fork, per questo la cosa più importante è revocare e sostituire le credenziali esposte.