Claude Code 2.1.268: cosa è stato corretto nelle regole deny e in MCP

Claude Code versione 2.1.268 è stata rilasciata il 10 settembre 2026, seguita il giorno dopo dalla 2.1.269. Dovresti aggiornare subito: in due casi, le regole deny che usi per impedire all’agente di accedere a .env e alle cartelle dei servizi erano inefficaci senza che fosse segnalato. Inoltre, il comando /mcp poteva stampare segreti dai tuoi file di configurazione nel terminale.

Tutto ciò che segue si basa sul changelog e sulla documentazione ufficiali di Anthropic così come risultavano il 17 settembre 2026, data del materiale di partenza. L’ultima versione a quella data era la 2.1.274. Descriviamo il funzionamento degli errori sulla base di quelle voci; i bypass non sono stati riprodotti sulla versione vulnerabile.

Per ulteriori istruzioni su come lavorare con Ailoot, consulta la documentazione.

Cosa è stato corretto in Claude Code 2.1.268 e 2.1.269?#

Quattro correzioni riguardano le regole di autorizzazione:

1. I divieti sui link simbolici non funzionavano. Le regole deny e ask scritte per directory collegate simbolicamente (/etc, /tmp, /var su macOS, /bin su Linux) non si attivavano quando un percorso veniva indicato con la sua posizione reale. Anche i comandi Bash ignoravano le regole deny scritte per un percorso tramite link simbolico.
2. Il divieto di lettura e modifica non funzionava insieme a env -C o eval. Se la stessa riga di comando conteneva un costrutto che il controllo delle autorizzazioni non riusciva ad analizzare, deny su Read o Edit poteva non attivarsi.
3. Una regola con “!” si applicava in modo più ampio del previsto. Una regola deny o ask che iniziava con ! si applicava oltre il file di impostazioni in cui era stata scritta. Ora si applica solo nel proprio ambito e una negazione isolata ! viene ignorata.
4. tee aggirava i divieti in scrittura. Le regole deny per Edit() e il controllo del percorso di scrittura non venivano applicati a un file creato dal comando Bash tee. L’autorizzazione Bash(tee:*) non copre più le scritture al di fuori delle directory di lavoro.

Queste versioni hanno anche corretto due problemi legati all’esposizione di segreti. WebFetch non resta più in attesa indefinitamente di una risposta da un server che mantiene aperta la connessione: la richiesta ora fallisce dopo 300 secondi e il timeout può essere configurato con la variabile CLAUDE_CODE_WEBFETCH_DEADLINE_MS. È stato inoltre eliminato l’uso persistentemente elevato della CPU nelle sessioni inattive prolungate.

Come funzionano i divieti in Claude Code?#

Claude Code ha tre elenchi di regole: deny (sempre vietato), ask (chiede prima di eseguire l’azione) e allow (consentito senza conferma). Quando l’agente sta per fare qualcosa, le regole vengono controllate rigorosamente in quest’ordine. Una regola deny corrispondente annulla qualsiasi allow per la stessa azione: una regola permissiva non può fare eccezione a un divieto.

Le regole sono memorizzate in tre posizioni: le regole utente in ~/.claude/settings.json, le regole di progetto in .claude/settings.json all’interno del repository e le regole locali in .claude/settings.local.json. Ecco un esempio di impostazioni che negano la lettura di un file con chiavi:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

Puoi vedere tutte le regole attive e il file da cui proviene ciascuna eseguendo /permissions in una sessione. Se una regola blocca la lettura, il divieto indica il nome della regola, cosa utile per il controllo qui sotto.

Quali errori hanno interessato i divieti e l’ambito delle regole?#

Gli errori riguardavano i controlli dei percorsi e dei comandi, oltre all’ambito delle regole provenienti da diversi file di impostazioni.

Primo caso: link simbolici. Su macOS, /etc, /tmp e /var sono link simbolici a cartelle reali sotto /private; su Linux, /bin è spesso un link simbolico simile. Se scrivevi una regola deny per una grafia del percorso ma l’agente vi accedeva usando l’altra (per esempio, la posizione reale invece del link simbolico), la regola non si attivava. Anche i comandi Bash ignoravano un divieto scritto per un percorso tramite link simbolico. Nella 2.1.268 entrambi i casi sono stati corretti: la regola ora si applica indipendentemente dalla grafia del percorso usata.

Secondo caso: env -C ed eval sulla stessa riga. Il controllo delle autorizzazioni analizza un comando per determinare a quali file accederà. Non riesce ad analizzare costrutti come env -C o eval. Il problema era che, quando un costrutto del genere appariva sulla riga, deny su Read o Edit poteva non essere applicato. Di conseguenza, il comando poteva aggirare il divieto di lettura o modifica di un file protetto.

Terzo caso: una regola con “!” si applicava oltre i propri limiti. Una regola che inizia con ! dovrebbe applicarsi solo all’interno del file di impostazioni in cui è scritta. Prima della 2.1.269, si applicava anche ad altre fonti di impostazioni. Ora il suo ambito è limitato al proprio file e una regola composta da un ! isolato viene ignorata.

Quarto caso: scrittura tramite tee. Il comando Bash tee può scrivere su un file. Il controllo del percorso di scrittura e le regole deny di Edit() non venivano applicati a quel file. Allo stesso tempo, l’autorizzazione Bash(tee:*) copriva le scritture al di fuori delle directory di lavoro. Nella 2.1.269 questi controlli hanno iniziato ad applicarsi alle scritture tramite tee: il divieto sul file entra in vigore e Bash(tee:*) copre solo le directory di lavoro.

Se usi divieti mirati — per bloccare .env, alcune cartelle di servizio o comandi pericolosi — dovresti controllare anche quelli. I passaggi sono riportati di seguito.

Perché /mcp poteva mostrare le tue chiavi?#

Le configurazioni dei server MCP conservano spesso le chiavi nelle variabili di ambiente e vi fanno riferimento tramite ${VAR}, così il file può essere archiviato in un repository senza includere i segreti. Il problema era che i comandi di visualizzazione (/mcp, /plugin, claude mcp list, claude mcp get) e i messaggi di errore di accesso MCP mostravano la configurazione con i valori già sostituiti. La chiave stessa compariva sullo schermo.

Un’altra correzione riguarda gli errori dei plugin e dei marketplace: potevano mostrare un token o una password dall’URL Git di origine.

Se l’output di /mcp o claude mcp list su una versione precedente è comparso in uno streaming, in uno screenshot, in un messaggio a un collega o in un log uscito dal tuo computer, anche automaticamente, considera esposte le chiavi delle tue configurazioni MCP e ruotale. Se l’output non ha mai lasciato il tuo computer, è sufficiente aggiornare. Abbiamo una guida separata sui server MCP e sulle configurazioni pronte all’uso: Server MCP di Claude Code.

Altre modifiche in queste versioni#

WebFetch e gli artefatti. In precedenza, una regola WebFetch senza dettagli in deny o ask si applicava anche alla lettura e alla modifica degli artefatti pubblicati. Dalla 2.1.268 non si applica più a essi. Per bloccare gli artefatti, serve una regola Artifact separata o una regola per il dominio, come WebFetch(domain:claude.ai). Se ti affidavi a un divieto WebFetch generico per proteggere dalla lettura degli artefatti, ricontrolla le impostazioni: la regola precedente non blocca più queste azioni.

WebFetch ora ha un timeout. Una richiesta a un server che mantiene aperta la connessione e non completa la risposta ora fallisce dopo 300 secondi. In precedenza, una richiesta del genere poteva rimanere bloccata a tempo indeterminato. Il comportamento può essere configurato con la variabile CLAUDE_CODE_WEBFETCH_DEADLINE_MS; impostarla a 0 disattiva il timeout.

È stato eliminato l’uso persistentemente elevato della CPU nelle sessioni inattive. Nelle sessioni inattive prolungate, un ciclo di inattività in Claude Code poteva causare un uso persistentemente elevato della CPU. Questo bug è stato corretto nella 2.1.268. Poteva interessare anche chi lascia le sessioni aperte tutto il giorno.

Installa la versione più recente. Nella 2.1.269 è comparso un nuovo bug: dopo che una sessione era rimasta attiva a lungo, i comandi Bash Git che leggevano soltanto dati iniziavano a chiedere l’autorizzazione. È stato corretto nella 2.1.270. Aggiorna quindi alla versione più recente (al 17 settembre 2026 era la 2.1.274); non fermarti alla 2.1.268 o alla 2.1.269.

Come aggiornare e verificare che i divieti funzionino?#

1. Verifica la versione attuale. Esegui claude --version nel terminale. Le correzioni dei problemi descritti sopra sono state rilasciate nelle versioni 2.1.268 e 2.1.269. Se il numero di versione è inferiore a 2.1.268, la tua versione non include ancora queste correzioni, anche se l’applicabilità di ciascun problema dipende dai percorsi, dai comandi e dalle regole che usi.
2. Aggiorna. La guida come aggiornare Claude Code alla versione più recente contiene istruzioni passo passo e indicazioni per la risoluzione dei problemi. Scegli la versione più recente; non fermarti alla 2.1.268.
3. Verifica il divieto. Non provare una regola su un vero .env: se il divieto non funziona, l’agente vedrà chiavi reali. Crea un file di test, per esempio secret-test.txt, contenente un testo qualsiasi, come “questo è un test”; aggiungi la regola "Read(./secret-test.txt)" all’elenco deny nel file .claude/settings.json del progetto; riavvia la sessione e chiedi: “leggi il file secret-test.txt e dimmi che cosa contiene”. Il comportamento atteso è un divieto che indica la tua regola. Se l’agente legge il file, in questo test il divieto non ha funzionato. Per prima cosa, controlla la sintassi nella sezione sopra e apri /permissions per vedere le regole attive e i file da cui sono state caricate. Il solo risultato del test non identifica la causa. Un singolo divieto dimostra che la regola per questo file funziona; non dice nulla sulle altre, quindi controllale una alla volta allo stesso modo.
4. Controlla il caso dei link simbolici se usi percorsi di questo tipo. Se hai divieti per /tmp, /etc o /var su macOS, o per /bin su Linux, ripeti il test per questi percorsi dopo l’aggiornamento.
5. Rivedi le regole con “!”. Se ne hai usate, controlla che ciascuna sia scritta nel file in cui deve applicarsi.

Se il divieto funziona ma Claude Code continua a non poter vedere i file che ti servono, consulta la spiegazione separata: perché Claude Code non riesce a vedere i file del progetto.

Se al momento non puoi aggiornare#

A volte devi rimandare un aggiornamento: non puoi modificare l’ambiente, il computer è di proprietà dell’azienda oppure devi finire l’attività in corso. Fino all’aggiornamento, puoi ridurre i rischi così:

• scrivi regole deny per entrambe le grafie del percorso, quella del link simbolico e quella della posizione reale (su macOS, i percorsi reali si trovano sotto /private);
• non combinare più comandi sulla stessa riga ed evita env -C ed eval nei comandi che chiedi all’agente di eseguire;
• non mostrare a nessuno l’output di /mcp, /plugin, claude mcp list o claude mcp get, e ruota le chiavi delle configurazioni MCP che potrebbero essere finite nelle mani di altri;
• ricorda che tee aggira il divieto su Edit: non considerare protetti i file se Bash è consentito.

Queste misure riducono la probabilità di specifici bypass, ma non sostituiscono la correzione. Aggiorna ed esegui il test della sezione precedente appena puoi.

Breve riepilogo#

Le versioni 2.1.268 e 2.1.269 hanno corretto quattro problemi di autorizzazione di Claude Code: link simbolici, righe con env -C ed eval, regole con “!” che si applicavano oltre il proprio file e scritture tramite tee. Separatamente, hanno corretto l’esposizione di segreti nell’output di /mcp e di token negli errori dei plugin. Controlla il numero della versione, aggiorna all’ultima release ed esegui il test con un file di prova descritto nella sezione precedente. Un divieto che indica la tua regola dimostra che il divieto ha funzionato in questo test. La sola presenza della regola nelle impostazioni non basta a verificarlo.

Per continuare a lavorare con i modelli, puoi andare su Ailoot.