Claude Code: password in 1.122 file su GitHub. Come controllare

👁 112 letture

L’11 agosto 2025, un utente di Claude Code ha segnalato su GitHub un bug, il numero 5544. Ha scritto che i comandi approvati nell’agente venivano salvati parola per parola nel file settings.local.json, comprese le chiavi API e i token. Nessuno di Anthropic ha risposto. Il 3 gennaio 2026, dopo 60 giorni di silenzio, un bot ha chiuso la segnalazione con la nota «not planned». Dieci mesi dopo, i ricercatori di Apiiro hanno misurato le conseguenze: su GitHub pubblico ci sono 1.122 copie di questo file con almeno un segreto autentico al loro interno.

Uso Claude Code ogni giorno, in una cartella con oltre 500 sottocartelle di progetti. Prima di scrivere questo articolo, l’ho scansionata. Qui trovi il risultato e i comandi per fare lo stesso sul tuo computer in due minuti.

Un clic che salva la password

Prima di eseguire la maggior parte dei comandi nel terminale, Claude Code chiede il permesso. Oltre alle normali opzioni «Sì» e «No», ce n’è una terza: «Sì, e non chiedermelo più». Questa aggiunge una regola al file .claude/settings.local.json nella cartella del progetto; da quel momento, i comandi corrispondenti vengono eseguiti senza altre richieste. È quanto risulta dalla documentazione delle impostazioni di Claude Code.

Il problema è che la regola può contenere il comando completo, anziché uno schema. Se chiedi all’agente di verificare perché non funziona l’accesso a un database su un server di test, potrebbe comporre un comando con la password recuperata dalla tua configurazione: senza password non può fare la verifica. Le richieste di autorizzazione possono comparire più volte durante una sessione, perciò dopo la decima in pochi leggono fino in fondo una riga lunga. Un clic, e la password finisce in chiaro nel file JSON. Apiiro ha riprodotto il problema con i modelli più recenti, Opus 5.5 e Fable 5.1: la causa è quindi lo strumento, non un modello specifico.

Claude Code cerca di tenere questo file fuori dal repository. Quando lo salva per la prima volta in un repository Git, lo aggiunge alla lista globale dei file ignorati sul tuo computer. Ma questa protezione non segue il progetto: non viene aggiunta al file .gitignore del repository, non copre una cartella che diventa un repository solo in seguito e non rimuove un file già incluso in un commit. Inoltre, spesso è l’agente stesso a inserirlo nel commit. In 539 dei 1.105 repository con segreti esaminati da Apiiro, il file era stato modificato in un commit firmato come co-creato da Claude. Le istruzioni per i commit dicono al modello di escludere .env e credentials.json, ma non menzionano il suo file di autorizzazioni.

1.122 file e 1.379 segreti

Shmulik Cohen e Matan Giladi di Apiiro hanno esaminato GitHub pubblico tra il 1° e il 3 novembre 2026. Hanno trovato 104.185 copie del file in 103.617 repository. In 1.122 di queste, pari all’1,1%, c’era un segreto. In tutto si trattava di 1.379 segreti diversi: 636 chiavi riconducibili a formati di fornitori noti e 743 password o token accanto all’indirizzo di un server pubblico.

Oltre un terzo permetteva di accedere direttamente a un database: 379 password per database e 122 chiavi di servizio Supabase. C’erano poi 43 credenziali SSH per server pubblici, alcune con password di root, 42 token per GitHub, GitLab e npm e 23 chiavi AWS. I file appartenevano soprattutto a singoli sviluppatori, ma tra i proprietari c’erano anche 63 organizzazioni, da associazioni studentesche a società di software. I casi più gravi comprendevano una chiave cloud di un produttore di database con privilegi di amministratore e la password del proprietario di un database in un’applicazione con documentazione medica. Una delle aziende avvisate ha confermato che la propria chiave era attiva. Le altre non sono state testate: qui «segreto» significa quindi un dato dall’aspetto autentico, non una credenziale di cui sia stato verificato l’accesso.

Due numeri sono particolarmente significativi. In metà dei repository con segreti, il file era presente da almeno 217 giorni; in 118 casi da oltre un anno. Anche cancellarlo non basta: le vecchie versioni nella cronologia Git contenevano altri 734 segreti in 509 repository, mentre 211 fork avevano copiato gli stessi dati da 74 progetti. Considerando anche la cronologia, il file condiviso settings.json e le conversazioni salvate con gli agenti, Apiiro ha contato 2.539 segreti in 1.994 repository.

I comuni scanner di segreti non rilevano una parte considerevole dei casi. Dei 1.122 file, gitleaks ne ha segnalati 564 e TruffleHog 643; 215 non sono stati rilevati da nessuno dei due strumenti. Gli scanner cercano chiavi con formati riconoscibili, mentre una password dopo PGPASSWORD= o sshpass -p sembra una parola qualsiasi in un normale comando.

Cosa ho trovato sul mio computer

La mia cartella di lavoro contiene 504 sottocartelle e 34 repository Git. Ho trovato un solo file settings.local.json, nella cartella principale, con 14 regole di autorizzazione. Lo script che cercava password, token, chiavi e indirizzi con password incorporata non ha trovato nulla. La cartella principale non è un repository, quindi il file non avrebbe comunque potuto finire su GitHub. Ci sono nove file condivisi settings.json; sei sono tracciati da Git in progetti dimostrativi e anche questi sono puliti.

Lo devo più a un’abitudine che alla prudenza: avvio Claude Code da un’unica cartella principale, così tutte le autorizzazioni finiscono in un solo file fuori da Git. Ho trovato qualcosa di più interessante altrove. Apiiro ha esaminato anche i file di memoria degli agenti e ne ha trovati con segreti in nove repository. Nel mio caso Claude Code gestisce oltre mille note di questo tipo. Il mio semplice scanner ha segnalato in due di esse una stringa che sembra una chiave: ora le controllerò manualmente. Sono fuori dai repository, ma restano normali file di testo sul disco.

Come controllare i file in due minuti

Su Linux, macOS o Git Bash per Windows, inizia elencando tutti i file di impostazioni di Claude Code nella cartella home:

find ~ -path '*/.claude/settings*.json' -not -path '*/node_modules/*' 2>/dev/null

Poi elenca quelli che contengono stringhe simili a segreti. Il comando mostra solo i nomi dei file, non i valori, quindi puoi eseguirlo anche con qualcuno accanto o mentre registri lo schermo:

find ~ -path '*/.claude/settings*.json' -not -path '*/node_modules/*' -print0 2>/dev/null |
 xargs -0 grep -lE 'PGPASSWORD=|MYSQL_PWD=|sshpass -p|mysql .*-p[^ ]|Bearer [A-Za-z0-9._-]{20,}|sk-[A-Za-z0-9_-]{20,}|gh[pousr]_[A-Za-z0-9]{30,}|AKIA[0-9A-Z]{16}|://[^:/" ]+:[^@/" ]+@'

In PowerShell su Windows, l’equivalente è:

Get-ChildItem $HOME -Recurse -Force -Filter 'settings*.json' -ErrorAction SilentlyContinue |
 Where-Object { $_.DirectoryName -like '*\.claude' } |
 Select-String -Pattern 'PGPASSWORD=|MYSQL_PWD=|sshpass -p|Bearer [A-Za-z0-9._-]{20,}|sk-[A-Za-z0-9_-]{20,}|gh[pousr]_[A-Za-z0-9]{30,}|AKIA[0-9A-Z]{16}|://[^:/" ]+:[^@/" ]+@' -List |
 Select-Object -ExpandProperty Path

Un risultato vuoto non è una garanzia: nessun modello di ricerca individua tutte le password, quindi controlla comunque a vista i file più lunghi. Poi, in ogni repository in cui lavori con un agente, verifica se Git traccia il file ora o lo ha tracciato in passato:

git ls-files .claude/
git log --all --oneline -- .claude/settings.local.json

Se entrambi i comandi non restituiscono risultati, è una buona notizia. Se tieni i progetti su GitHub, cerca nel codice path:.claude/settings.local.json user:tuo-nomeutente oppure org:tua-azienda. Ogni risultato corrisponde a un file che chiunque può leggere.

Chiave esposta: prima cambiala, poi fai pulizia

L’ordine è importante. Per prima cosa, nel pannello del fornitore - database, cloud o GitHub - revoca e rigenera ogni password, token e chiave che il file ha mai contenuto. Eliminare il file dal repository non annulla la fuga: la vecchia versione rimane nella cronologia, nei fork e nelle copie locali di chi l’ha già scaricata. Controlla anche i log di accesso del fornitore per verificare se qualcuno ha usato la chiave senza autorizzazione.

Solo dopo passa alla pulizia:

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git commit -m "Non tracciare le impostazioni locali di Claude Code"

Il file resta sul disco, ma Git smette di tracciarlo; la voce in .gitignore viene condivisa con il progetto e raggiunge chiunque lo cloni. Apri anche il file, se non è mai stato in Git, e rimuovi le regole con password. In seguito puoi ripulire la cronologia del repository con git filter-repo, ma è solo una rifinitura: una chiave cambiata non è più utile a nessuno, mentre nessuna riscrittura della cronologia può salvare una chiave che non è stata cambiata.

Per il futuro bastano due abitudini. Non inserire i segreti direttamente nei comandi: chiedi all’agente di usare una variabile, per esempio $DATABASE_URL, così la regola memorizzerà il nome della variabile e non la password. Inoltre, autorizza schemi come Bash(npm run:*) invece dei singoli comandi. Nei progetti di gruppo, aggiungi .claude/settings.local.json ai modelli di .gitignore e tratta le cartelle degli agenti (.claude/, .cursor/, .gemini/) come i file .env. Ho scritto di ciò che tengo nei file per gli agenti in un articolo su CLAUDE.md e AGENTS.md; ho raccolto una panoramica più ampia su come l’IA cambia la sicurezza in un approfondimento sull’IA nella cybersecurity nel 2026.

Anthropic promette prototipi

Apiiro ha condiviso i risultati con Anthropic prima della pubblicazione. Il 7 novembre, su Hacker News, Boris Cherny, responsabile di Claude Code, ha risposto ammettendo che finora lo strumento non ripuliva i segreti. Ha annunciato che il team avrebbe valutato alcune soluzioni, tra cui il rilevamento di questi comandi in modalità auto e una semplice scansione dei segreti. Il team sta «valutando cosa può fare per impedirlo», ha scritto. Ha aggiunto che Claude Code ignora il file in Git già al momento della sua creazione e che, secondo lui, le copie su GitHub erano state aggiunte manualmente da qualcuno. Al momento non è ancora disponibile una correzione. La segnalazione numero 5544 è chiusa e bloccata, mentre il file di cui parla continua a essere salvato a ogni clic su «non chiedermelo più».

Domande frequenti

Il problema riguarda solo Claude Code?

Tra i 16 agenti confrontati, Apiiro ha confermato solo in Claude Code il meccanismo che salva per intero il comando in un file di progetto. Ha però trovato segreti anche nelle esportazioni delle conversazioni di Cursor e aider, nei file di memoria degli agenti e nelle impostazioni di autorizzazione automatica di Copilot in VS Code.

Basta eliminare il file dal repository?

No. La vecchia versione resta nella cronologia Git, nei fork e nelle copie locali. L’unica reazione efficace è cambiare ogni password e chiave presente nel file; la pulizia del repository viene dopo.

La modalità auto protegge da questo problema?

In parte. Cherny consiglia la modalità auto invece delle regole di autorizzazione permanenti. Quando un lettore ha fatto notare che anche in modalità auto l’agente può chiedere l’autorizzazione per un comando sensibile, il responsabile di Claude Code gli ha dato ragione. La protezione più sicura è non inserire affatto i segreti nei comandi.

Fonti

• Apiiro: Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub (5 novembre 2026, aggiornato l’8 novembre)
• The Hacker News: il file «Don’t Ask Again» di Claude Code espone password e chiavi in 1.122 copie pubbliche su GitHub (7 novembre 2026)
• GitHub, anthropics/claude-code, segnalazione #5544 (11 agosto 2025, chiusa il 3 gennaio 2026)
• Documentazione di Claude Code: file di impostazioni e priorità
• Scansione della mia cartella di lavoro, 9 novembre 2026 (numeri senza percorsi né valori)

// continua a leggereTest in italiano di Kimi K3.1 Pro contro Claude Opus 5.5, GPT-6 Astra e Gemini (2026)Strumenti IAClaude Fable 5.2 e Mythos 5.2 sono usciti: cosa cambiaNotizieClaude Code nel Pentagono: le accuse riportate da WIREDNotizie