Apiiro ha riferito che alcuni comandi approvati in Claude Code possono salvare password o token in chiaro nel file di progetto .claude/settings.local.json. Se il file viene pubblicato su GitHub, anche le credenziali inserite nel comando possono diventare pubbliche. Nel campione di copie pubbliche raccolto dall’1 al 3 novembre 2026, Apiiro ha trovato segreti in 1.122 file su 104.185 esaminati; lo studio è stato pubblicato il 5 novembre.
Come un’approvazione può salvare una credenziale
Scegliendo “Yes, and don’t ask again”, Claude Code può memorizzare il comando approvato come regola di autorizzazione in .claude/settings.local.json. Se quel comando contiene una password, una chiave API o un token scritto direttamente al suo interno, il valore può restare nel file in chiaro. Il rischio descritto da Apiiro nasce quando quel file locale finisce in un repository pubblico.
La raccolta di Apiiro riguardava copie pubbliche su GitHub: i suoi numeri descrivono quel campione, non il tasso di esposizione di tutti gli utenti di Claude Code o dei repository privati.
Che cosa contano le cifre
Le 1.122 copie contenevano 1.379 segreti distinti. In altre parole, il primo dato conta file, il secondo credenziali trovate in quei file. Apiiro ha riferito che una società aveva confermato attiva una chiave esposta; le altre credenziali non sono state testate.
Un conteggio più ampio, che comprendeva anche la cronologia Git e altri file legati agli agenti di programmazione, arrivava a 2.539 segreti in 1.994 repository e 63 organizzazioni. Non è il totale delle credenziali nei 1.122 file: si tratta di un insieme più esteso e di un’unità di conteggio diversa.
Perché la pulizia del repository non basta
I resoconti descrivono un’esclusione Git globale, impostata sul singolo sviluppatore. Non aggiunge automaticamente una regola al .gitignore del progetto, non protegge un file già tracciato e non accompagna il repository quando viene condiviso. Eliminare il file dal progetto corrente, inoltre, non cancella le versioni già presenti nella cronologia, né le copie in fork o cloni.
Se una credenziale potrebbe essere finita in un repository, revocala o ruotala prima di ripulire file e cronologia Git.
Quale ordine seguire in caso di esposizione
Per una credenziale potenzialmente pubblicata, Apiiro indica di revocarla o ruotarla per prima. Poi conviene controllare il file locale e il repository, togliere il file dal tracciamento Git e aggiungere una regola di esclusione al .gitignore del progetto. La verifica deve includere anche la cronologia, perché la rimozione della copia corrente non elimina i commit precedenti o le copie già distribuite. Evitare di inserire segreti letterali nei comandi autorizzati riduce il rischio che vengano salvati nelle impostazioni.
Perché gli scanner possono non trovare tutti i segreti
Nel gruppo di 1.122 file con credenziali, Apiiro ha riferito che 215 non erano stati segnalati né da Gitleaks né da TruffleHog. Una password inserita in un comando shell o in un’intestazione di richiesta può non assomigliare ai formati riconoscibili di una chiave di servizio. Per questo, nel caso di un file di impostazioni esposto, la ricerca nella configurazione e nella cronologia resta importante anche quando si usano strumenti di scansione.
