Se usi Claude Code, controlla il file .claude/settings.local.json prima di pubblicare un repository: le autorizzazioni permanenti possono conservare comandi che includono password, token o chiavi API. Se una credenziale è stata caricata su GitHub, va trattata come potenzialmente compromessa: revocala o ruotala subito, poi rimuovi le copie dal progetto e dalla cronologia. Cancellare soltanto il file non rende inutilizzabile una chiave già esposta.
Che cosa hanno scoperto i ricercatori
Nella ricerca pubblicata il 5 novembre 2026, Apiiro descrive un rischio concreto legato alle approvazioni permanenti dei comandi. Esaminando 104.185 copie pubbliche di .claude/settings.local.json, ha trovato 1.122 file contenenti almeno un segreto, per un totale di 1.379 credenziali distinte. Una ricerca più ampia, che comprende cronologia Git e altri file, porta a 2.539 segreti in 1.994 repository. Non significa che ogni installazione di Claude Code perda credenziali, né che tutti i segreti identificati siano ancora attivi. I ricercatori non hanno provato ad accedere ai servizi usando le credenziali trovate.
Perché il comando autorizzato può finire nel file
Quando Claude Code propone un comando e l’utente seleziona l’approvazione permanente, la regola può includere il comando così come è stato autorizzato. Se nella stringa compare un token passato direttamente a un programma, quel valore può rimanere in chiaro nelle impostazioni. La documentazione ufficiale Anthropic sulle impostazioni distingue .claude/settings.json, condivisibile nel progetto, da .claude/settings.local.json, destinato alle preferenze locali.
Claude Code prova a escludere automaticamente il file locale da Git quando lo crea. Ma l’esclusione locale non protegge una copia già tracciata, un repository creato successivamente o un clone su un altro computer. È importante controllare lo stato reale del repository, non affidarsi al nome local.
Come controllare se il file è tracciato in Git
Apri un terminale nella cartella del tuo progetto e verifica prima se il file esiste. Non incollarne il contenuto in chat o in un issue pubblico.
git ls-files -- .claude/settings.local.json .claude/settings.json
git log --all -- .claude/settings.local.json .claude/settings.jsonIl primo comando mostra i file attualmente tracciati; il secondo cerca modifiche nella cronologia raggiungibile dal repository. Se il risultato è vuoto, non dimostra che altri file o vecchi cloni siano sicuri. Per controllare se un file non tracciato viene ignorato, puoi usare git check-ignore -v .claude/settings.local.json. Evita di copiare negli strumenti di diagnostica il contenuto di un file con segreti.
Cosa fare quando trovi una chiave o una password
- Individua il servizio coinvolto senza divulgare il valore completo della credenziale; controlla il progetto e il contesto dell’approvazione.
- Revoca o ruota la credenziale presso il fornitore. Per chiavi cloud o token di pubblicazione verifica anche i privilegi e gli accessi effettuati durante l’esposizione. Se sono credenziali aziendali, coinvolgi subito il responsabile della sicurezza.
- Rimuovi il dato dai file correnti e assicurati che non sia più incluso nelle regole di autorizzazione. Configura
.gitignorenel repository, anziché contare soltanto sulle esclusioni globali del tuo computer. - Valuta la bonifica della cronologia seguendo una procedura di riscrittura concordata con il team: riscrivere commit pubblicati può interferire con i cloni e non elimina i fork già esistenti.
- Verifica le copie remote e i log di accesso al servizio, poi applica controlli preventivi prima di nuovi commit.
La Cloud Security Alliance sottolinea che rimuovere un segreto dall’ultima versione del file non lo cancella dalla storia Git. Perciò la rotazione della credenziale viene prima della semplice pulizia del repository.
Come prevenire nuove esposizioni
Non approvare in modo permanente comandi che incorporano password o token direttamente nella riga di comando. Preferisci meccanismi di autenticazione e gestori di segreti adatti al progetto; controlla sempre il comando effettivo prima di scegliere «non chiedere più». Inserisci nel repository regole di esclusione esplicite per i file locali, senza presumere che bastino a proteggerli se sono già tracciati. Aggiungi una revisione delle modifiche prima di ogni commit e uno scanner dei segreti: può ridurre il rischio, ma non riconosce necessariamente password nascoste in comandi ordinari.
| Situazione | Priorità |
|---|---|
| File locale non tracciato, senza segreti | Controllare regole di esclusione e approvazioni future |
| File con token pubblicato nel repository | Revocare o ruotare il token, poi bonificare |
| Segreto presente solo in un vecchio commit | Ruotare comunque: la cronologia può essere accessibile |
| Scanner automatico senza segnalazioni | Non presumere assenza di password incluse nei comandi |
Il problema riguarda ogni uso di Claude?
No. La ricerca si concentra soprattutto sulle impostazioni di Claude Code nei repository di sviluppo, non su qualunque conversazione con Claude. Il rischio specifico nasce dalla combinazione fra comandi con segreti, approvazioni persistenti e pubblicazione accidentale dei file. Per comprendere altri controlli sul codice e le differenze fra funzioni, trovi il nostro approfondimento su Claude Security e le scansioni dei repository. Per i limiti nell’esecuzione di strumenti puoi consultare anche la guida sui permessi di Claude Code: un rifiuto del modello e una regola locale di autorizzazione sono problemi differenti.
In sintesi: verifica file locali, stato Git e vecchi commit; se una credenziale è stata esposta, revocala prima di ripulire il repository. Il controllo più efficace è impedire che un segreto venga scritto in una regola di autorizzazione riutilizzabile.
Entra nella conversazione
Condividi il tuo punto di vista: non serve creare un account. I contributi restano soggetti alla moderazione editoriale.