Nel resoconto pubblicato da The Hacker News il 7 novembre 2026, Apiiro ha riferito di aver trovato segreti in 1.122 copie pubbliche di .claude/settings.local.json, su 104.185 copie esaminate in 103.617 repository GitHub. Il meccanismo descritto riguarda l’approvazione permanente di un comando esatto: se il comando contiene una password o un token scritto alla lettera, quel valore può finire nel file di impostazioni locale. Per una delle aziende contattate, la chiave esposta era attiva, secondo quanto riportato da The Hacker News.
Se un comando può contenere una credenziale letterale, preferisci un pattern e usa variabili gestite da un secret manager: il file delle impostazioni può finire nel repository.
Come un comando approvato può salvare un segreto
Quando l’utente sceglie “Yes, and don’t ask again” per un singolo comando, Claude Code può salvare una regola di autorizzazione per quel comando in .claude/settings.local.json. Se nel comando è inserita direttamente una credenziale, anche questa può essere salvata in chiaro. Una regola basata su un pattern è diversa: non deve contenere una password o un token letterale.
Claude Code aggiunge il file alle esclusioni Git globali dell’utente quando lo crea per la prima volta in un repository Git. L’esclusione vale per la configurazione Git di quell’utente: non elimina file già inviati al repository e non aggiunge una regola condivisa al .gitignore del progetto.
Che cosa indicano i conteggi
Apiiro ha contato 1.379 segreti nei file pubblici correnti .claude/settings.local.json. Il totale più ampio di 2.539 segreti comprende invece anche versioni precedenti, file condivisi .claude/settings.json e registri di chat degli agenti, distribuiti in 1.994 repository.
| Ambito | Contenuti compresi | Totale attribuito ad Apiiro |
| File locali correnti | 1.122 copie pubbliche con almeno un segreto | 1.379 segreti |
| Raccolta più ampia | Versioni precedenti, impostazioni condivise e chat salvate degli agenti | 2.539 segreti in 1.994 repository |
Apiiro ha inoltre riferito di aver trovato 734 segreti in versioni precedenti, distribuiti in 509 repository. In 211 fork di 74 repository sarebbero comparse copie degli stessi segreti.
La cronologia Git può conservare le copie
Eliminare il file dalla versione corrente del progetto non cancella le copie già presenti nella cronologia Git o nei fork. Anche gli scanner hanno rilevato solo una parte dei file nei controlli riferiti da Apiiro, eseguiti senza il passaggio di verifica degli strumenti.
| Esito della scansione | File su 1.122 |
| Segnalati da gitleaks | 564 |
| Segnalati da TruffleHog | 643 |
| Non segnalati da nessuno dei due | 215 |
I risultati dei due scanner possono sovrapporsi: non sono categorie da sommare. I 215 file non segnalati da nessuno dei due sono conteggiati a parte.
Come intervenire se una credenziale è finita nel repository
Apiiro raccomanda di cercare il file sia nel progetto corrente sia nella cronologia Git. Se trovi una credenziale, ruotala prima di procedere alla pulizia: rimuovere il file dal ramo corrente non cancella le versioni già registrate o copiate nei fork.
Dopo aver ruotato le credenziali, la risposta indicata comprende la rimozione delle regole locali che contengono valori segreti, lo scollegamento del file dal tracciamento Git e l’aggiunta di una regola al .gitignore del repository. Per i comandi successivi, Apiiro raccomanda di usare variabili di un gestore di segreti invece di inserire password o token direttamente, e di autorizzare pattern anziché singoli comandi che contengono credenziali.
Una variabile d’ambiente non è una garanzia assoluta: nella community di Claude Code, un partecipante ha osservato che un processo con accesso sufficiente può leggere anche queste variabili. La raccomandazione di usare un secret manager evita di inserire il valore letterale nel comando, ma resta importante controllare quali processi possono accedere al segreto.
Limitare la lettura dei file è un controllo distinto
Un partecipante a una discussione della community di Claude Code attribuisce alla documentazione il consiglio di usare regole di diniego Read per proteggere percorsi sensibili; afferma inoltre che .claudeignore non controlla l’accesso degli strumenti ai file. Queste regole limitano la lettura dei percorsi indicati. Per credenziali già salvate in un comando o nella cronologia Git, restano necessari la rotazione e l’intervento sui file e sul repository.
