GitHub Copilot aggiunge una sandbox locale: cosa cambia quando l'agente esegue codice sul PC

GitHub ha introdotto nel Copilot app un sistema di sandboxing locale pensato per ridurre l’impatto di comandi eseguiti involontariamente dagli agenti sul computer dell’utente.

La funzione interessa le sessioni che operano su repository e working tree locali e consente di definire quali risorse possono essere raggiunte. Il controllo riguarda filesystem, connessioni di rete e credenziali utilizzabili dagli strumenti invocati dall’agente.

La configurazione resta separata per ogni progetto e non modifica le sessioni già attive. GitHub precisa inoltre che il meccanismo è in public preview, quindi le modalità operative possono ancora cambiare. L’approccio è rilevante soprattutto quando Copilot deve eseguire comandi, installare dipendenze o interagire con servizi esterni durante un’attività di sviluppo.

Come funziona il sandbox locale di Copilot

Il sandbox esegue gli strumenti richiamati dall’agente all’interno di un ambiente controllato dal sistema operativo. Per ogni progetto l’utente può definire una sandbox policy che stabilisce l’accesso a file, rete e credenziali. Per il filesystem sono disponibili percorsi aggiuntivi in lettura e scrittura, percorsi aggiuntivi in sola lettura e directory esplicitamente negate. Una regola di diniego più specifica continua a prevalere anche quando una cartella superiore dispone di permessi più ampi.

La rete segue un’impostazione analoga. È possibile consentire o bloccare l’accesso a Internet e alla rete locale; queste restrizioni possono influenzare installazione dei pacchetti, chiamate API, server di sviluppo e altri strumenti che richiedono connettività. Su Linux esiste però una limitazione precisa: il sandbox non può controllare separatamente l’accesso alla rete locale dei processi generati, come comandi shell e server MCP o LSP locali. La restrizione continua invece a valere per operazioni eseguite direttamente dal processo dell’applicazione.

Anche le credenziali Git e GitHub CLI possono essere escluse dalla sessione. Disattivarle impedisce, per esempio, di effettuare operazioni HTTPS autenticate o utilizzare GitHub CLI per attività che richiedono autenticazione. La protezione non sostituisce quindi le autorizzazioni del repository: agisce a un livello diverso, limitando ciò che i processi avviati dall’agente possono utilizzare sul computer.

Le restrizioni diventano effettive nelle nuove sessioni

Il comportamento temporale della configurazione è un dettaglio importante. Le modifiche a filesystem, rete e credenziali entrano in vigore quando viene avviata una nuova sessione oppure dopo il riavvio di quella esistente; non alterano retroattivamente una sessione già in esecuzione. Per applicare una nuova policy mantenendo la cronologia è disponibile il comando /restart-session.

Durante una sessione locale è inoltre possibile attivare il sandbox con /sandbox on oppure disattivarlo con /sandbox off. L’override riguarda quella specifica sessione e non modifica automaticamente l’impostazione predefinita del progetto. Se un’operazione richiede privilegi che la policy nega, Copilot può proporre di eseguirla temporaneamente al di fuori del sandbox; nelle configurazioni aziendali, un amministratore può impedire agli utenti di utilizzare questa possibilità.

Un’altra garanzia riguarda i sistemi che non sono in grado di applicare la policy richiesta: il comando sandboxed fallisce invece di essere eseguito senza protezione. La distinzione è importante perché evita che una restrizione configurata dall’utente venga trasformata silenziosamente in un’esecuzione libera. Il sandbox locale non copre invece le sessioni cloud né quelle eseguite su host remoti. GitHub mantiene inoltre separate le impostazioni del sandbox dell’app e quelle di Copilot CLI.