Cosa cambia davvero con la disponibilità generale
GitHub ha annunciato il 7 ottobre 2026 la disponibilità generale del sandboxing locale per GitHub Copilot CLI, GitHub Copilot app e sessioni VS Code basate su Agent Host. I comandi e gli strumenti avviati dall’agente possono essere confinati con regole su filesystem, rete, credenziali e altre capacità del sistema operativo.
Il motore indicato da GitHub è Microsoft eXecution Container, o MXC: traduce una policy comune in controlli nativi su Windows, macOS e Linux. La policy si applica all’esecuzione dei tool, indipendentemente dal modello scelto. Cambiare modello non allarga né restringe automaticamente il confine.
La novità utile non è quindi “Copilot ora è sicuro”, ma la possibilità di rendere osservabile e amministrabile ciò che i comandi locali possono raggiungere. La protezione reale dipende dalla policy effettiva della sessione, dai default della superficie usata e dalle eccezioni che autorizzi.
Worktree, permessi e sandbox risolvono problemi diversi
Una worktree separa i file di due attività concorrenti, ma non impedisce a un processo di leggere altre cartelle della macchina. Le approvazioni decidono quando chiedere il consenso prima di un’azione. La sandbox limita ciò che il processo può fare anche dopo che l’azione è partita.
Questi livelli si sommano. Puoi avere una sessione in worktree con richieste di approvazione frequenti ma senza isolamento del sistema; oppure una sessione con meno prompt, ma confinata da una policy stretta. Per i task più rischiosi servono entrambi: decisione umana sulle azioni sensibili e limiti tecnici sul loro raggio.
- Worktree
- Separa checkout e modifiche Git. Non è un confine di sicurezza per filesystem, rete o credenziali.
- Approvazione
- Chiede una decisione umana prima di una specifica azione. Non limita da sola ciò che un comando approvato può raggiungere.
- Sandbox
- Applica restrizioni tecniche a processi e figli su file, rete e capacità, secondo la policy effettiva.
I default sono comodi, non equivalgono al minimo privilegio
Nella configurazione documentata per Copilot CLI, i comandi in sandbox possono scrivere nella directory di lavoro corrente e nelle cartelle temporanee. Dentro un repository, anche .git è scrivibile; le parti del repository sopra la directory corrente restano leggibili ma non scrivibili. Percorsi aggiuntivi richiedono regole esplicite.
La rete internet in uscita è consentita per default, mentre la rete locale è disattivata. Anche l’autenticazione Git e GitHub CLI è attiva per default: i processi ricevono valori sostitutivi e un proxy locale usa le credenziali reali soltanto verso destinazioni approvate. Puoi disattivare queste capacità o mascherare altre variabili d’ambiente, associandole a host HTTPS specifici.
Nell’app Copilot la sandbox è disattivata per default, salvo una policy enterprise che la imponga. Le impostazioni dell’app e quelle della CLI sono separate: cambiare una non modifica automaticamente l’altra. Prima di iniziare una sessione, controlla la superficie che stai davvero usando.
- Filesystem: concedi scrittura soltanto al workspace e alle cartelle indispensabili.
- Internet: spegnilo quando il task è locale oppure usa regole host strette.
- Rete locale: abilitala solo se devi raggiungere un server di sviluppo o un servizio privato preciso.
- Git e gh: disattiva le credenziali se la sessione non deve fare push, creare pull request o usare API autenticate.
- MCP e language server: verifica che vengano eseguiti nella sandbox quando sono locali e che i tool remoti abbiano scope minimo.
Un pilot in cinque passaggi, prima del repository importante
Esegui la prima prova su una cartella sintetica, senza segreti e senza remote di produzione. L’obiettivo non è misurare quanto codice genera Copilot: è verificare che i confini dichiarati blocchino davvero gli accessi non previsti.
I comandi slash seguenti appartengono a Copilot CLI. Nell’app Copilot si usano /sandbox on e /sandbox off per la sessione; le impostazioni di progetto restano separate. Non copiare la configurazione da una superficie all’altra dando per scontato che sia identica.
- Abilita la sandbox e controlla lo stato della sessione corrente.
- Leggi la policy effettiva, non soltanto le preferenze salvate.
- Previsualizza la policy applicata a un comando che userai, senza eseguirlo.
- Prova scrittura nel workspace, accesso a un percorso negato e rete con dati sintetici.
- Registra blocchi, bypass proposti e differenze tra risultato atteso e osservato.
/sandbox enable
/sandbox status
/sandbox policy
/sandbox policy npm install
Poi chiedi all’agente di:
1. creare un file di prova soltanto nel workspace;
2. leggere un percorso sintetico che hai negato nella configurazione;
3. contattare un host non consentito;
4. fermarsi al primo blocco senza chiedere un bypass.
Registra:
- policy effettiva;
- azione consentita o bloccata;
- eventuale richiesta di bypass;
- file realmente creati o modificati;
- rete e credenziali effettivamente usate. Il bypass è il punto in cui il confine può sparire
Quando un comando viene bloccato, Copilot può proporre di ripeterlo con accesso più ampio. Le richieste di bypass sono abilitate per default nella CLI. Puoi approvare un singolo tentativo, mantenere il blocco oppure, se la policy lo consente, disattivare la sandbox per il resto della sessione.
La documentazione GitHub avverte che un comando eseguito in bypass salta il mascheramento delle credenziali e il proxy della sandbox. Torna quindi a vedere l’ambiente ordinario del tuo account, compresi eventuali valori reali disponibili al processo. Il bypass non concede privilegi amministrativi, ma può rimuovere proprio i limiti che stavi testando.
La risposta prudente a un blocco non è sempre “consenti”. Prima usa /sandbox policy sul comando, identifica il percorso o l’host necessario e valuta una regola più stretta. Se l’azione è occasionale e comprensibile, un bypass singolo è meno ampio della disattivazione per tutta la sessione.
- Non approvare un bypass se il comando o la motivazione non sono chiari.
- Non disattivare la sandbox per risolvere un errore di configurazione non diagnosticato.
- Dopo una modifica alla policy, riavvia la sessione quando richiesto e ricontrolla lo stato.
- Tratta ogni bypass come un evento da registrare insieme a comando, motivo ed esito.
- Nelle policy enterprise, valuta allowBypass: false per i workload nei quali l’eccezione non è accettabile.
Supporto e limiti cambiano tra superfici e sistemi operativi
GitHub richiede Windows 11 25H2 con KB5124010 o Windows 11 26H1 con KB5124006, oppure versioni successive indicate nella documentazione. Su Linux servono bubblewrap 0.5.0 o successivo e slirp4netns disponibili nel PATH. Su macOS l’accesso al portachiavi è disattivato per default e può essere controllato con una specifica opzione Seatbelt.
C’è anche una differenza di stato da non nascondere. Il changelog GitHub del 7 ottobre presenta il sandboxing locale come generalmente disponibile anche per le sessioni VS Code con Agent Host. Al 13 ottobre, la pagina VS Code sulle approvazioni etichetta però il sandboxing dei comandi come Preview su macOS, Linux e WSL2 ed Experimental su Windows. Prima di standardizzare un rollout, verifica versione, tipo di sessione e documentazione mostrata dal client installato.
Le policy enterprise possono imporre sandbox attiva, bloccare il bypass, negare credenziali, restringere host e percorsi e far fallire l’esecuzione se il backend di isolamento non è disponibile. Questo supporto non si estende automaticamente a ogni chat o terminale di VS Code: la documentazione limita l’ambito alle sessioni compatibili con Agent Host.
Checklist per un rollout controllato
- Superficie e versione del client annotate: CLI, app Copilot o VS Code Agent Host.
- Prerequisiti del sistema operativo verificati prima del primo task.
- Sandbox attiva confermata nella sessione, non dedotta dalle impostazioni salvate.
- Policy effettiva archiviata con percorsi, rete, credenziali, MCP e LSP.
- Internet, rete locale, Git e gh disattivati quando non servono.
- Percorsi negati provati con file sintetici e senza dati personali.
- Bypass spento o limitato; ogni eccezione viene revisionata e registrata.
- Task iniziale piccolo, reversibile e privo di credenziali di produzione.
- Diff, test e comportamento restano soggetti a review umana.
- Una modifica alla policy viene applicata a una nuova sessione e verificata di nuovo.
Client e versione: <VALORI>
Sistema operativo: <VALORE>
Sessione: <CLI / APP / VS CODE AGENT HOST>
Sandbox status: <ON / OFF / MANAGED>
Scrittura consentita: <PERCORSI>
Lettura consentita: <PERCORSI>
Percorsi negati: <PERCORSI SINTETICI>
Internet: <OFF / HOST CONSENTITI>
Rete locale: <OFF / MOTIVO>
Git credentials: <OFF / MOTIVO>
gh credentials: <OFF / MOTIVO>
MCP e LSP locali in sandbox: <SÌ / NO / NON USATI>
Bypass: <OFF / APPROVAZIONE SINGOLA>
Prove eseguite: <ELENCO>
Esito osservato: <ELENCO>
Scostamenti: <NESSUNO / ELENCO>
Decisione: <STOP / CORREGGI POLICY / AMPLIA UN SOLO ACCESSO> Fonti primarie e stato della verifica
Disponibilità generale, superfici supportate, MXC e separazione tra modello e isolamento provengono dal changelog GitHub del 7 ottobre 2026. Default, comandi, credenziali mascherate, bypass, prerequisiti e configurazione derivano dalla documentazione GitHub corrente. Lo stato indicato da VS Code è riportato separatamente perché non coincide pienamente con la formulazione del changelog.
La fotografia è aggiornata al 13 ottobre 2026. Non ho eseguito un pilot reale con Copilot CLI, app o VS Code: la procedura è derivata dalle fonti primarie e va provata sulla versione installata prima di usarla con codice o dati importanti. Default, prerequisiti, nomi delle impostazioni e disponibilità per client possono cambiare.
- GitHub Changelog: local sandboxing generalmente disponibile ↗
- GitHub Docs: usare il sandboxing locale ↗
- GitHub Docs: configurare filesystem, rete, credenziali e bypass ↗
- GitHub Docs: impostazioni enterprise per la sandbox ↗
- VS Code: approvazioni e stato del sandboxing dei comandi ↗
- DottorLone: sandbox, rete e log nel pilot di un agente cloud →
- DottorLone: checklist prima di accettare codice generato dall’AI →