Claude Code: quel «sì» può scrivere la password

Claude Code, l’assistente di Anthropic che scrive codice e lancia comandi sul tuo computer, in modalità manuale chiede il permesso prima di eseguirne molti. Più volte nella stessa sessione di lavoro. E a un certo punto ti offre la risposta più comoda: «Yes, and don’t ask again». Sì, e non chiedermelo più.

Sembra un clic risparmiato. Secondo una ricerca di Apiiro, azienda di sicurezza informatica, può diventare la strada con cui una password arriva su internet.

Quel bottone fa due cose. Autorizza il comando. E salva una regola. Quando la regola è il comando esatto, dentro resta tutto quello che il comando conteneva.

Cosa scrive quel «sì»

La parte certa sta nelle guide ufficiali di Anthropic. Quando usi Claude Code dal terminale e rispondi «Yes, and don’t ask again» a un comando Bash, cioè dato a un interprete di comandi, salva una regola di permesso nel file .claude/settings.local.json, dentro il progetto. Nell’estensione per VS Code, il programma in cui molti scrivono codice, puoi scegliere il file di destinazione, compreso quello condiviso con il team. Da lì in poi la regola autorizza i comandi corrispondenti anche nelle sessioni successive, salvo regole più forti che impongano una domanda o un divieto.

Fin qui è una comodità. Il punto è cosa c’è dentro la regola.

Secondo The Hacker News, che riprende la ricerca, la regola copre quello che la richiesta di permesso offriva. A volte è uno schema, come «npm test *», che autorizza i comandi che iniziano con npm test. A volte è un comando preciso, carattere per carattere. E quando è il comando preciso, ogni password o token, la chiave in forma di codice con cui un programma si fa riconoscere, resta salvato lì, in chiaro.

C’è un dettaglio che toglie anche l’ultimo alibi all’idea di «basta stare attenti a cosa scrivi». Il segreto può non averlo scritto tu. Apiiro racconta il percorso così: chiedi a Claude Code di controllare un database, cioè l’archivio dove stanno i dati di un’azienda o di un’app, o di capire perché un accesso fallisce. Il comando che propone si porta dentro la password presa da un file di configurazione del tuo computer, perché senza non funzionerebbe. Tu leggi, approvi, ed è fatta.

Credi di autorizzare un’azione. A volte stai anche archiviando una frase.

I numeri di Apiiro, e il loro limite

Le cifre che seguono vengono tutte da Apiiro, e conviene leggerle sapendolo: è un’azienda che vende sicurezza per lo sviluppo con l’AI, e The Hacker News riprende i suoi dati, senza un controllo indipendente. La pagina di Apiiro riporta il 5 novembre 2026. The Hacker News, nell’articolo del 7 novembre, scrive che Apiiro ha comunicato quei risultati «ieri», e le fonti lette non spiegano la differenza fra le due date.

La raccolta è stata fatta su GitHub fra l’1 e il 3 novembre. Apiiro conta 104.185 copie pubbliche del file, in 103.617 repository, cioè le cartelle di progetto pubblicate online. Di queste, 1.122, circa l’1,1%, contengono almeno quello che chiama «real secret», un segreto vero. In tutto conta 1.379 segreti diversi, e più di un terzo li classifica come credenziali per entrare direttamente in un database: 379 password e 122 chiavi di servizio di Supabase, un servizio che ospita database. Poi 43 accessi SSH, cioè accessi a distanza ai server, 42 token per GitHub, GitLab e npm, tre siti dove si pubblica il codice, e 23 chiavi AWS, i servizi cloud di Amazon. Apiiro non ne ha verificato il funzionamento. Contando anche le vecchie versioni del file, il file di impostazioni che i team condividono apposta e le chat degli agenti salvate nei progetti, Apiiro arriva a 2.539 segreti in 1.994 repository.

Le organizzazioni coinvolte sono 63, per lo più aziende di software di ogni dimensione. Nell’elenco dei casi più pesanti ci sono la chiave di un produttore di database per il proprio cloud, i server affittati su internet, con poteri di gestione, un token di produzione di Square, il servizio di pagamenti, esposto da un’agenzia di software, e la password di proprietario del database di un’app per cartelle cliniche, gestita da un’azienda di servizi informatici.

Adesso il limite, che Apiiro scrive di suo pugno. «Real secret» indica una credenziale che ha il formato giusto o che punta a un server pubblico. Una credenziale che funziona è un’altra cosa, e nessuna è stata provata: «No credential was used or tested», nessuna credenziale è stata usata o testata. Apiiro ha avvisato i proprietari dei casi citati il 2 e il 3 novembre, e un’azienda ha confermato che la sua chiave era attiva.

Il numero conta le chiavi lasciate in vista. Quante aprano ancora una porta, Apiiro l’ha lasciato fuori dal conteggio.

Claude Code prova a tenerlo a casa

Va detto: il rischio che il file finisca online, Claude Code l’ha previsto. La prima volta che lo scrive in un progetto gestito con git, il programma che tiene la storia delle versioni del codice, lo aggiunge all’elenco personale dei file da ignorare. La guida di Anthropic è esplicita: «You don’t need to gitignore it yourself», non devi occupartene tu, a meno che il file l’abbia creato a mano.

Allora perché 1.122 copie con un segreto stanno su GitHub? Apiiro dà la sua spiegazione. Quell’elenco vive nelle impostazioni di una persona, su un computer. Copre il caso comune. Restano scoperti una cartella che diventa un progetto git in un secondo momento, una copia del progetto su un’altra macchina, un file già salvato nella storia. E la regola non entra mai nel .gitignore del progetto, il file che viaggia insieme al codice.

In 539 dei 1.105 repository che ha ricostruito, Apiiro ha trovato un salvataggio firmato anche da Claude come coautore che ha toccato quel file. Ne deduce che spesso a salvarlo sia Claude stesso. È una deduzione, e la firma da sola non racconta chi abbia deciso cosa. Se Apiiro legge bene, chi propone il comando può essere anche chi salva il file nella storia del progetto.

La protezione esiste. Resta sul computer di chi ha cliccato, mentre il progetto parte.

Cancellare il file arriva tardi

Se scopri il file online, l’istinto è cancellarlo. Git però ha buona memoria: conserva le versioni precedenti, e le copie fatte da altri, i cosiddetti fork, tengono le loro. Apiiro trova 734 segreti in 509 repository soltanto nelle vecchie versioni, di solito perché il file era stato cancellato. E 211 fork di 74 repository portano gli stessi segreti degli originali.

Intanto i file stanno lì. Al 2 novembre ognuno di quelli con un segreto era ancora sul ramo principale del suo progetto, e nel repository mediano era stato salvato la prima volta 217 giorni prima.

Anche gli strumenti fatti apposta faticano. Apiiro ha passato tutti i file a gitleaks e TruffleHog, due programmi che scovano i segreti nel codice. Dei 1.122 file, il primo ne segnala 564, il secondo 643, e 215 non li segnala nessuno dei due. Il motivo è semplice: questi programmi cercano formati noti di chiavi, e una password scritta in mezzo a un comando sembra una parola qualunque in una riga qualunque.

GitHub, poi, è solo il posto dove si poteva contare. Lo stesso file resta in chiaro sul computer di chi ha cliccato, e può uscire in altri modi: dentro uno zip, in una cartella sincronizzata, in un pacchetto pubblicato. Apiiro ricorda il caso di Shai-Hulud, il worm, cioè il programma malevolo che si copia da solo, che nel settembre 2025 lanciava TruffleHog sui file delle sue vittime.

Per questo l’ordine conta più della pulizia. Prima cambi la password. Poi togli il file.

Quattro segnalazioni, tutte chiuse da un bot

La storia ha un precedente. L’11 agosto 2025 un utente ha aperto una segnalazione sul GitHub di Claude Code: i comandi approvati con dentro una credenziale restano salvati in chiaro in quel file. Il 3 gennaio 2026 un bot l’ha chiusa dopo 60 giorni di inattività, con l’etichetta «not planned», non in programma.

Apiiro cita altre tre segnalazioni: due sulla stessa famiglia di problemi, una sui permessi concessi dall’estensione per VS Code. Sono state chiuse tutte dallo stesso bot, una come doppione, l’ultima il 5 novembre. Nessuna, scrive Apiiro, ha ricevuto una risposta da Anthropic.

Un bot che chiude per inattività applica una regola di pulizia, e da quella chiusura una scelta di Anthropic non si ricava. Si ricava un fatto più modesto: la prima segnalazione ha quasi quindici mesi, e Apiiro dice di aver riprodotto il comportamento con i modelli più recenti, Opus 5.5 e Fable 5.1. Dipende dal programma, precisa, e dal modello no. Nelle fonti lette manca una risposta di Anthropic alla ricerca.

E gli altri? Apiiro ha confrontato le guide di 16 agenti di programmazione: Claude Code è l’unico confermato a scrivere per impostazione predefinita il comando completo in un file del progetto. Il confronto riguarda la documentazione, però, e l’abitudine pericolosa è più larga: Apiiro trova segreti anche nelle chat degli agenti salvate nei progetti, nei file di memoria, nelle note di consegna e nelle impostazioni di approvazione automatica di Copilot in VS Code. Cambia il file. Resta il gesto di mettere un segreto in un comando che qualcuno registra.

Due decisioni in un clic

Questa, per come la leggo io, è una storia di comunicazione prima che di informatica.

Ad agosto Anthropic ha pubblicato un dato che ti ho già raccontato parlando di Claude Pro e del sì che diventa automatico: in Claude Code gli utenti approvavano il 97% delle richieste di permesso. La conclusione è sua, ed è precisa: un tasso così alto «suggests many users are clicking through reflexively rather than reviewing each command», suggerisce che molti utenti clicchino per riflesso invece di esaminare ogni comando. Nello stesso articolo del 7 agosto 2026, Anthropic riporta che secondo dati di giugno il 62% degli utenti aveva usato l’opzione che salta i permessi oppure «don’t ask again» sui comandi Bash.

Una domanda ripetuta, per come la vedo io, cambia natura. La prima volta è una domanda. Alla ventesima è un ostacolo, e un ostacolo si scavalca. Chi progetta una richiesta di consenso pensa di chiedere attenzione, e rischia di allenare un riflesso. Lo stesso filone l’ho toccato con lo studio sugli analisti che seguivano l’agente credendo di decidere da soli.

Il dettaglio più istruttivo però è un altro. L’etichetta del bottone parla delle domande future, e promette di toglierne. Le guide spiegano che viene salvata una regola; Apiiro e The Hacker News descrivono il caso in cui la regola contiene il comando esatto, segreti compresi. La mia lettura: quell’etichetta mette in primo piano le domande di domani e lascia sullo sfondo quello che resta scritto. In un clic chiudi due decisioni: se autorizzare questa riga adesso, e se tenere una regola che resta lì finché qualcuno non la cancella.

Secondo me ti riguarda anche se non hai mai visto un terminale. Se fai firmare, spuntare, confermare qualcosa dieci volte, a un cliente o a un collaboratore, rischi di insegnargli a smettere di leggere. E se una sola conferma porta con sé due conseguenze, la seconda rischia di scoprirla qualcun altro.

Il consenso ripetuto rischia di smettere di essere una scelta. E di diventare un gesto.

Se a programmare è qualcun altro

Facile pensare che sia roba da sviluppatori. Guarda però chi compare negli esempi di Apiiro: un’agenzia di software, un’azienda di servizi informatici con un’app per cartelle cliniche. Fornitori. Aziende che lavorano per altre aziende.

Se il tuo sito, il tuo gestionale o la tua app li ha fatti qualcuno che usa un agente AI, la password del tuo database può essere passata da un comando approvato con un clic. Non vuol dire che sia successo. Vuol dire che è una domanda da fare.

Stesso discorso se Claude Code hai iniziato a usarlo tu, per costruirti un piccolo strumento o sistemare un sito. Una chiave lasciata in giro costa più di quanto sembri: l’ho raccontato con il LLMjacking, dove chi trova una chiave usa i modelli di AI a spese tue. La direzione giusta è quella di 1Password per gli agenti: l’agente entra, e la password la tiene qualcun altro.

Come portarlo nel tuo lavoro

Se usi Claude Code, o chi lavora per te lo usa, i passi sono questi. I primi sei vengono dalla ricerca di Apiiro, l’ultimo è un consiglio mio.

1. Cerca il file. Su GitHub, nella tua organizzazione, cerca .claude/settings.local.json e .claude/settings.json. Controlla la storia di ogni progetto, anche dove il file oggi non c’è più.
2. Se c’è un segreto pubblicato, cambialo per prima cosa. Password, token, chiavi: tutto quello che il file ha contenuto. La pulizia viene dopo, perché la storia e i fork se lo tengono.
3. Smetti di tracciare il file con git. Il comando è git rm –cached .claude/settings.local.json: la copia sul tuo computer resta. Poi aggiungi il file al .gitignore del progetto, quello che viaggia con il codice.
4. Apri la copia sul tuo computer. Anche se non è mai uscita da lì, leggi l’elenco dei comandi approvati e cancella ogni regola che contiene un segreto.
5. Tieni i segreti fuori dai comandi. Richiamali come variabili, cioè nomi segnaposto, per esempio $DB_URL, da un gestore di segreti: la regola conserva il nome, il valore resta altrove.
6. Approva schemi, invece di singoli comandi. Una regola come Bash(npm run:*) dice cosa si può fare senza portarsi dietro una password. E le cartelle degli agenti, come .claude/ o .cursor/, si trattano come contenitori di segreti.
7. Se hai un fornitore, chiediglielo. Usi agenti AI sul mio progetto? Dove stanno le mie password quando l’agente lavora? Controlli quelle cartelle prima di pubblicare? Bastano tre domande, e dalla risposta capisci parecchio.

Resta una domanda, e la lascio a te: l’ultima volta che hai cliccato «sì, e non chiedere più», avevi letto cosa stavi approvando?

Domande frequenti

Claude Code pubblica da solo le mie password su GitHub?

La regola resta sul tuo computer, nel file del progetto, e quando è il comando esatto conserva anche i segreti che contiene. Diventa leggibile a tutti su GitHub se quel file entra nella storia del progetto e la storia viene caricata in un repository pubblico. Apiiro segnala che in 539 dei 1.105 repository ricostruiti un salvataggio firmato anche da Claude come coautore ha toccato il file, e ne deduce che spesso a salvarlo sia Claude stesso.

Se il mio progetto è privato sono al sicuro?

Apiiro ha contato solo le copie pubbliche, quindi sui progetti privati i numeri mancano. Il file però resta in chiaro nella cartella del progetto e, secondo Apiiro, può uscire anche dentro uno zip, una cartella sincronizzata o un pacchetto pubblicato. Vale la pena aprirlo e togliere le regole che contengono un segreto.

I segreti trovati in quei 1.122 file funzionano?

Non è stato verificato. Apiiro non ha provato nessuna credenziale: conta come segreto un valore con il formato di una chiave nota, o una password accanto all’indirizzo di un server pubblico, con il controllo di un revisore AI. Un’azienda ha confermato che la sua chiave era attiva. I ricercatori non dicono se qualcuno abbia usato questi segreti.

Riguarda solo Claude Code?

Fra i 16 agenti di programmazione di cui Apiiro ha confrontato le guide, Claude Code è l’unico confermato a scrivere per impostazione predefinita il comando completo in un file del progetto. Apiiro ha trovato segreti anche nelle chat degli agenti salvate nei progetti, nei file di memoria e nelle impostazioni di approvazione automatica di Copilot in VS Code.

Anthropic ha risposto o ha corretto il problema?

Le fonti lette non riportano una risposta di Anthropic alla ricerca. Le guide ufficiali spiegano che il file viene aggiunto all’elenco personale dei file da ignorare. Apiiro scrive di aver riprodotto il salvataggio del comando con i modelli più recenti, Opus 5.5 e Fable 5.1, e che le segnalazioni pubbliche citate non hanno ricevuto risposta da Anthropic.

Devo smettere di usare «non chiedere più»?

Apiiro consiglia altro: approvare schemi invece di singoli comandi e tenere i segreti fuori dalla riga di comando, richiamandoli come variabili. Così la regola salvata contiene il nome della variabile, e il segreto resta altrove.

Fonti

• Apiiro, «Coding Agents Are Leaking Your Secrets to GitHub»
• The Hacker News, 7 novembre 2026
• Anthropic, guida di Claude Code ai permessi
• Anthropic, guida di Claude Code alle impostazioni
• Anthropic, articolo sulla modalità automatica in Claude Code
• GitHub, segnalazione 5544
• GitHub, segnalazione 11982
• GitHub, segnalazione 13106
• GitHub, segnalazione 91270