Claude Code sandbox: la rete si apre per un solo comando

Con Claude Code sandbox, installare una dipendenza non impone più di estendere il perimetro di rete a tutto il resto di un job di Claude Code. Il 14 settembre 2026, Claude Code 2.1.271 ha introdotto nella modalità automatica in sandbox l’accesso alla rete circoscritto al singolo comando: l’host del registry autorizzato per l’installazione può quindi richiudersi non appena quel comando termina.

Claude Code sandbox: che cosa cambia davvero

Qui entrano in gioco due livelli di sicurezza distinti di Claude Code. Per capire la novità, bisogna considerarli separatamente.

La modalità automatica decide se una chiamata a uno strumento può essere eseguita. Un classificatore dedicato valuta l’azione alla luce della richiesta. La guida precedente alla modalità automatica di Claude Code descrive il modello generale dei permessi.

La sandbox decide a cosa può accedere un comando shell mentre è in esecuzione. Limita le scritture sui file e instrada il traffico di rete attraverso un proxy che verifica l’host di destinazione.

La versione 2.1.271 collega questi due livelli in modo più stretto. In modalità automatica con sandbox, una chiamata Bash, PowerShell o Monitor può ora includere un elenco allowed_domains. Claude Code valuta insieme il comando e gli host di cui ha bisogno. Quegli host vengono aperti soltanto per quel comando, mentre la sandbox rifiuta tutti gli altri. La voce del changelog definisce esplicitamente questo perimetro.

Quel campo in snake case non coincide con sandbox.network.allowedDomains nel file settings.json.

Prima di questa release, approvare un nuovo host nella sandbox poteva produrre un’autorizzazione più estesa. Un’approvazione manuale resta valida per il resto della sessione corrente; se viene salvata, può persistere anche nelle sessioni successive. La modalità automatica può inoltre memorizzare la propria decisione su host e porta. Il nuovo campo modifica invece la portata durante l’esecuzione, anche quando viene riutilizzato il verdetto del classificatore: l’apertura della rete appartiene al comando corrente.

La novità riguarda esclusivamente la combinazione indicata nella release: modalità automatica, sandbox e chiamate Bash, PowerShell o Monitor. Le sessioni manuali, i comandi fuori dalla sandbox, gli strumenti integrati per i file e i job che non usano la rete non beneficiano di questo perimetro ristretto.

Il calcolo utile è il perimetro dei permessi, non un piano più economico

Il prezzo delle licenze Claude Code non cambia. Anthropic non ha annunciato costi separati, un nuovo SKU o risultati prestazionali legati ai domini per comando.

L’equazione utile misura l’ampiezza dell’autorizzazione che occorre giustificare:

standing grant = approved host × every later command that can reuse it

command-scoped grant = approved host × the reviewed command

Prendiamo l’installazione di una dipendenza che deve raggiungere registry.npmjs.org. In precedenza, la scelta operativa era spesso scomoda: interrompere un job non presidiato per decidere sull’accesso alla rete oppure autorizzare in anticipo il registry, accettando che ogni comando successivo nella sandbox potesse raggiungerlo. Ora la modalità automatica può approvare l’host insieme all’installazione e richiuderlo prima che proseguano build, test, packaging e revisione.

Questo incide su due voci di costo, pur lasciando invariata la fattura dell’abbonamento. I team di piattaforma hanno meno eccezioni permanenti da progettare e rimuovere. Chi si occupa della revisione di sicurezza può valutare una coppia comando-host, invece di considerare quell’host disponibile per tutto il resto del job.

Il percorso di verifica mantiene comunque un costo computazionale. Sugli account Enterprise e sugli account dei provider con tariffazione a consumo citati nella documentazione Anthropic sulle modalità di autorizzazione, le verifiche del classificatore consumano token e aggiungono un round trip. La release non pubblica benchmark sui tempi e per questo articolo non è stata eseguita alcuna prova cronometrata: non sarebbe quindi corretto promettere secondi risparmiati.

Chi può sfruttare la novità già da domani

Un founder che esegue un lungo job di build

Un founder può lasciare che Claude Code ripristini le dipendenze vincolate dal lockfile di un repository SaaS e prosegua poi con test e code review, senza tenere aperto il registry pubblico anche per queste fasi. Il vantaggio è un job che continua a lavorare senza trasformare un download necessario in un’uscita di rete permanente per l’intera sessione.

Un tech lead di agenzia che passa da un repository cliente all’altro

Un’agenzia può vincolare il package host di un cliente all’installazione che ne ha bisogno, anziché salvare un’altra eccezione a livello di progetto. Si riduce così il lavoro di pulizia dei permessi e diventa più difficile che un comando della fase successiva invii codice del cliente a un host aperto soltanto per gestire le dipendenze.

Un responsabile di piattaforma o sicurezza che governa agenti non presidiati

Un team di piattaforma può mantenere sia le regole di blocco valide per tutta l’organizzazione sia i vincoli sui domini gestiti, mentre i comandi ordinari richiedono un accesso più ristretto entro quella policy. Anche la traccia della verifica diventa più chiara: questo comando aveva bisogno di questo host per questa azione. Non dimostra che l’host fosse sicuro per tutto ciò che l’agente ha fatto in seguito.

Un build engineer che separa installazione e test

Un build engineer può trattare il ripristino dei pacchetti come fase connessa alla rete e la suite di test come fase offline. Se, una volta conclusa l’installazione, un test compromesso o uno script inatteso prova a contattare il registry, non eredita l’apertura concessa al comando precedente, a meno che un’altra regola permanente non autorizzi già quell’host.

Come configurare Claude Code sandbox per un’installazione circoscritta

Il modo più chiaro per osservare la novità è usare un repository con un package-lock.json sotto controllo di versione e dipendenze risolte tramite un solo registry noto. npm indica npm ci per le installazioni automatizzate pulite: richiede un lockfile, va in errore se lockfile e manifest non coincidono, rimuove un’eventuale directory node_modules e non modifica né il manifest né il lockfile. L’opzione --ignore-scripts impedisce l’esecuzione degli script del ciclo di vita dei pacchetti durante l’installazione. Questi comportamenti sono documentati da npm.

1. 1

   Verifica la versione di Claude Code

   Esegui il controllo della versione indicato nel changelog:

   claude --version

   Usa la versione 2.1.271 o una build successiva che includa la funzionalità.

2. 2

   Avvia la modalità automatica in una sandbox fail-closed

   Per una singola sessione, combina la modalità automatica con una sandbox che debba avviarsi correttamente e non possa riprovare fuori dal perimetro un comando bloccato:

   claude --permission-mode auto --settings '{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}'

   La configurazione usa i controlli documentati --permission-mode, --settings, failIfUnavailable e allowUnsandboxedCommands. Su macOS la sandbox è integrata. Linux e WSL2 richiedono bubblewrap e socat; Windows nativo non è supportato dalla sandbox integrata. Configurazione e limiti delle piattaforme sono descritti nella guida alla sandbox.

3. 3

   Assegna all’installazione un compito ben delimitato

   Invia questa richiesta, sostituendo l’host del registry se il lockfile usa un registry privato:

   Installa esattamente le dipendenze presenti in package-lock.json con npm ci --ignore-scripts. Questo comando può raggiungere soltanto registry.npmjs.org. Non salvare l’host nelle impostazioni del progetto o dell’utente. Al termine dell’installazione, esegui la suite di test come comando separato e senza accesso alla rete. Fermati se l’installazione richiede qualsiasi altro host.

   Il campo allowed_domains non va digitato manualmente. Claude Code costruisce la chiamata allo strumento shell e la modalità automatica valuta l’host richiesto insieme alla chiamata.

4. 4

   Controlla che il passaggio successivo parta senza rete

   Apri /sandbox, esamina la scheda Config della configurazione risolta e verifica che registry.npmjs.org non sia già presente in un allowedDomains permanente o in una regola WebFetch salvata. Lascia quindi partire il comando di test separato. Un tentativo di rete da quel comando dovrà ottenere la verifica di un proprio insieme di domini oppure verrà rifiutato dalla policy esistente.

Il dettaglio che spesso trae in inganno è il lockfile. Un package lock può puntare a un registry privato, a un host Git o all’URL diretto di un tarball. Indicare soltanto registry.npmjs.org non sposta lì quelle dipendenze. Controlla gli host effettivamente risolti, mantieni l’elenco preciso e lascia che il comando si interrompa quando il lockfile richiede una destinazione inattesa.

Che cosa non risolve l’accesso di rete per comando

L’accesso di rete circoscritto al comando restringe il momento in cui un host è raggiungibile. Non certifica l’affidabilità dell’host, non ispeziona ogni richiesta cifrata e non rende sicuro il codice scaricato.

Il proxy integrato di Anthropic filtra per nome host e, per impostazione predefinita, non ispeziona il contenuto TLS. All’interno del comando autorizzato, un processo può raggiungere qualsiasi percorso consentito su quell’host. Anche i processi figli avviati dal comando condividono il perimetro della sandbox: per questo npm ci --ignore-scripts è un buon esempio didattico. Esclude dall’installazione gli script del ciclo di vita dei pacchetti, ma non verifica i pacchetti scaricati.

Le policy gestite continuano ad avere priorità sulla funzionalità. strictAllowlist può bloccare tutto ciò che non rientra nell’elenco configurato, mentre allowManagedDomainsOnly può limitare gli host autorizzati alle impostazioni gestite. Le regole di blocco esplicite restano valide. I domini per comando non aggirano questi controlli.

Anche il tentativo fuori dalla sandbox è un caso limite concreto. Di norma Claude Code dispone di una via d’uscita per i comandi che la sandbox non riesce a eseguire. Impostare allowUnsandboxedCommands su false è importante: impedisce che un’installazione fallita trasformi silenziosamente la domanda «quale host può raggiungere questo comando?» in «questo comando può essere eseguito fuori dalla sandbox?».

Che cosa fare lunedì

Conviene agire questa settimana se Claude Code viene usato in modalità automatica per aggiornare dipendenze, svolgere manutenzione notturna o eseguire job di build non presidiati e i registry dei pacchetti sono oggi inseriti in un’allowlist ampia della sandbox. La nuova funzionalità offre un motivo concreto per verificare se quelle autorizzazioni permanenti possono essere rimosse.

È meglio aspettare se l’organizzazione adotta una policy di rete gestita che autorizza intenzionalmente il registry per ogni comando, oppure se un container esterno o il runner CI applica già regole di uscita più strette per processo. Il nuovo campo può comunque aggiungere difesa in profondità, ma non sostituisce il perimetro già operativo.

La novità non incide su chi non usa la modalità automatica con la sandbox o svolge attività che non chiamano mai Bash, PowerShell o Monitor attraverso la rete.

La mossa da fare lunedì è circoscritta: verifica Claude Code 2.1.271 o una versione successiva, scegli una sola installazione di dipendenze governata da lockfile, avviala in modalità automatica dentro una sandbox fail-closed, indica soltanto l’host del registry previsto e dimostra poi che il comando di test successivo non può riutilizzare quel percorso di rete. Rimuovi un’autorizzazione permanente al registry solo dopo che questa verifica è riuscita nel tuo ambiente.

Se vuoi vedere il prossimo cambiamento di piattaforma calato nel workflow su cui incide, iscriviti alla newsletter.