GitHub Copilot: sandbox locale disponibile, come limita file, rete e credenziali

La sandbox locale di GitHub Copilot limita il perimetro in cui gli strumenti dell’agente possono operare; non significa che il modello sia automaticamente locale. La disponibilità generale annunciata il 7 ottobre 2026 riguarda Copilot CLI, l’app e Agent Host in VS Code nei percorsi supportati. La data e i prodotti coinvolti sono riportati nel changelog GitHub.

Per una PMI che sviluppa software o affida modifiche a un assistente, il punto è rendere coerenti obiettivo e accessi. Un agente incaricato di correggere un componente non ha necessariamente bisogno di leggere tutte le cartelle del computer, usare qualsiasi credenziale o raggiungere ogni destinazione. Il perimetro tecnico deve riflettere il lavoro assegnato, con una prova che verifichi anche gli accessi vietati.

Quali controlli descrive GitHub per la sandbox locale?

La documentazione GitHub su sandbox cloud e locali descrive la tecnologia MXC su Windows, macOS e Linux per limitare strumenti, file, rete e credenziali, con policy organizzative dove supportate. Il comportamento concreto dipende dal client e dal percorso usato. Il nome della funzione non basta a stabilire che ogni strumento aperto sul computer sia incluso nel medesimo confine.

Il progetto deve quindi identificare dove viene eseguito l’agente e quali comandi attraversino la sandbox. Anche la configurazione organizzativa va letta nel suo perimetro, senza attribuirle un effetto universale su client o modalità diverse. Una policy è utile quando il team sa a chi si applica e può osservare cosa accade davanti a un accesso non consentito.

L’annuncio indica che la funzione è inclusa senza costo aggiuntivo, mentre il piano Copilot conserva le proprie condizioni: il riferimento è la release ufficiale. Questo non rende gratuito l’intero ambiente di sviluppo né il lavoro necessario per configurarlo e mantenerlo.

Autorizzazione dell’azione e isolamento sono la stessa cosa?

Una richiesta di permesso chiede se una operazione possa essere eseguita. La sandbox limita le risorse raggiungibili dal processo. Se l’operazione approvata viene eseguita in un ambiente troppo ampio, può avere accessi non necessari anche quando l’intento iniziale è corretto. Se il perimetro è troppo stretto, il compito può bloccarsi. I controlli devono quindi essere coerenti, non intercambiabili.

Il team deve evitare approvazioni vaghe, come accesso a tutto il computer per risolvere un singolo blocco. L’eccezione dovrebbe riguardare una necessità riconoscibile e mantenere il confine del progetto. Altrimenti la configurazione perde significato proprio durante le attività più difficili, quando l’agente incontra dati o comandi inattesi.

Quali cartelle dovrebbe poter leggere un agente di sviluppo?

Il punto di partenza è il repository del compito e ciò che serve davvero per eseguirlo. Cartelle di altri clienti, documenti personali e archivi amministrativi non sono automaticamente pertinenti. Anche dentro il progetto possono esistere file che richiedono una gestione diversa, come dati di produzione o materiale esportato per diagnosi. La disponibilità sul disco non equivale a una autorizzazione di lettura.

Il team dovrebbe creare una mappa semplice: sorgenti, test, dipendenze e risultati generati. Ogni area ha uno scopo. Un agente che deve modificare l’interfaccia può avere bisogno dei componenti e dei test, ma non di un archivio completo di dati clienti. Preparare un ambiente con input minimizzati rende più facile verificare accessi ed errori senza esporre materiale estraneo.

La guida su AI e sicurezza dei dati collega questo perimetro al processo aziendale. Il controllo deve includere il risultato: file generati, log e screenshot possono contenere informazioni provenienti dall’ambiente. Limitare la lettura è utile, ma occorre anche sapere dove vengano salvati gli esiti e chi possa consultarli.

Come delimitare rete e credenziali per il lavoro sul codice?

Lo sviluppo può richiedere accesso a dipendenze, documentazione e servizi di test. Non significa che il processo debba usare le credenziali di produzione o raggiungere qualsiasi endpoint. L’azienda dovrebbe scegliere account dedicati e ambienti di prova, lasciando alle persone autorizzate i passaggi con effetti esterni. Una chiave disponibile al processo può estendere il suo potere oltre i file del repository.

Le destinazioni di rete vanno motivate rispetto al compito. Quando un comando tenta di raggiungere un servizio nuovo, il team verifica che cosa stia facendo e perché. Non conviene approvare una apertura ampia solo per eliminare un errore di installazione o un test fallito. Prima si legge l’esito, poi si decide se la necessità sia legittima e proporzionata.

Il tema si collega alle restrizioni di rete dei Claude Managed Agents, che riguardano un altro prodotto e un diverso ambiente. Il principio comune è documentare il confine effettivo; le impostazioni non si trasferiscono automaticamente da un sistema all’altro.

Una software house può lavorare su un CRM proprietario?

Scenario ipotetico. Una software house italiana usa Copilot per preparare una modifica alla ricerca nel CRM di un cliente. L’ambiente contiene sorgenti e dati di test minimizzati, mentre il database produttivo resta fuori dal mandato. L’agente propone il codice, esegue i controlli autorizzati e restituisce un diff. Revisione e rilascio mantengono il processo previsto dal team.

Il pilota verifica che l’agente possa leggere il componente interessato e non accedere a una cartella estranea. Si prova anche un comando che richiede una destinazione non prevista, usando materiale innocuo e un ambiente di test. L’obiettivo non è dimostrare invulnerabilità, ma raccogliere evidenza che la configurazione rispetti i confini scelti per quel percorso.

Il responsabile controlla che i test non richiedano credenziali reali per comodità. Se il progetto dipende da un servizio esterno, si prepara una modalità di prova adeguata oppure si lascia quel passaggio alla procedura autorizzata. L’assistente può ridurre lavoro ripetitivo senza diventare il punto in cui vengono raccolti tutti gli accessi del cliente.

Un e-commerce può affidare all’agente una modifica del tema?

Secondo scenario ipotetico. Una PMI vuole correggere il filtro di una categoria nel proprio e-commerce. Il compito riguarda codice e dati fittizi, con una preview separata dal negozio live. L’agente non dispone automaticamente del pannello ordini o dei permessi per pubblicare. La sandbox viene configurata attorno al repository e agli strumenti necessari per la verifica locale.

La prova include lettura dei file previsti, scrittura nel componente assegnato e generazione di risultati di test. Si controlla che un errore non spinga l’agente a usare una cartella diversa o una sessione amministrativa già aperta. L’operatore deve poter comprendere perché una richiesta di accesso aggiuntivo sia necessaria prima di concederla.

Il valore si misura sulla modifica corretta e verificata. La velocità con cui viene prodotto un diff non basta: servono comportamento in preview, assenza di regressioni pertinenti e un percorso di rilascio leggibile. La sandbox limita alcune possibilità operative, mentre la qualità del risultato richiede ancora revisione e prova dell’interfaccia.

Sandbox locale significa poter lavorare offline?

No: isolamento locale e luogo di esecuzione del modello sono piani diversi. La novità sui modelli Ollama nella Copilot CLI affronta il rilevamento di modelli locali e una modalità offline esplicita. Non si deve attribuire quella funzione alla sandbox o assumere che il solo isolamento impedisca ogni collegamento di rete.

La distinzione aiuta a scegliere la configurazione per codice riservato. Il team deve sapere quale modello riceva il contenuto, dove girino gli strumenti e quali dati escano dall’ambiente. Una risposta completa richiede leggere provider, autenticazione, rete e impostazioni del client. Una singola etichetta come locale non descrive l’intero percorso.

La guida a Copilot AI aiuta anche a distinguere GitHub Copilot da prodotti con lo stesso nome rivolti ad altri compiti. In questo articolo il contesto è lo sviluppo software. Le condizioni di un assistente per documenti aziendali non vanno trasferite automaticamente a un agente che esegue strumenti nel repository.

Che cosa provare prima di estendere la configurazione al team?

Il collaudo deve verificare percorsi consentiti e vietati con file innocui. Si osservano lettura, scrittura, rete e uso delle credenziali nel percorso supportato. Il responsabile controlla anche la richiesta di eccezione e il comportamento dopo un rifiuto. Un blocco che viene aggirato attraverso un altro strumento non rappresenta il controllo desiderato dal progetto.

Le prove vanno ripetute quando cambia il client o il modo in cui viene avviato l’agente. Una configurazione verificata in un percorso non dimostra automaticamente l’effetto in un altro. Il registro dovrebbe indicare versione, ambiente e risultato, senza diventare un archivio di segreti. Questa evidenza permette al team di capire se una modifica abbia alterato il perimetro operativo.

La gestione degli errori degli agenti in produzione con Aqua riguarda un tema collegato: un flusso utile deve rendere leggibili anche fallimenti e condizioni anomale. Per lo sviluppo, il blocco di una azione deve produrre una spiegazione sufficiente a decidere il passo successivo, senza richiedere aperture generiche.

La sandbox può certificare la sicurezza del codice prodotto?

La sandbox può limitare effetti degli strumenti, ma il codice scritto può comunque contenere errori, vulnerabilità o regole applicative sbagliate. Un agente potrebbe produrre una modifica che supera i test esistenti e gestisce male un caso non coperto. La revisione deve leggere il comportamento introdotto e confrontarlo con il compito, non soltanto verificare che l’esecuzione sia avvenuta dentro un ambiente limitato.

Il programma Anthropic OSS Scanner affronta un altro livello, quello delle segnalazioni su progetti open source idonei. Anche lì un report richiede verifica e triage. Strumenti di analisi, isolamento e revisione possono completarsi, ma nessuno deve essere presentato come certificazione universale del software aziendale.

L’uso di ChatGPT per programmare segue lo stesso criterio operativo: proposta, verifica e responsabilità restano distinguibili. Il team deve sapere chi accetta il diff e quali prove siano necessarie prima di un rilascio. La disponibilità di un assistente non cambia da sola la definizione di codice pronto.

Controllo del perimetro prima della prima modifica

Identifica repository, client e percorso di esecuzione. Usa dati di test e permessi minimi. Prova un accesso consentito e uno vietato, senza materiale sensibile. Verifica che le richieste di eccezione descrivano l’azione concreta. Controlla dove finiscono log e risultati. Mantieni revisione e rilascio separati dalla capacità dell’agente di eseguire strumenti.

Come mantenere coerenti i controlli quando l’agente usa più strumenti?

Un progetto può combinare editor, terminale, browser e servizi esterni. Il controllo deve seguire il passaggio fra questi strumenti, perché una operazione limitata nel terminale potrebbe essere tentata da un altro percorso. La mappa del processo dovrebbe indicare dove gira ogni componente e quali risorse può raggiungere. Questo permette di osservare il confine reale, anziché attribuire alla sandbox una copertura non verificata.

Il Claude SDK per browser e computer use rappresenta un esempio di ambiente che lo sviluppatore deve costruire e controllare separatamente. Non è una estensione automatica della sandbox Copilot. Se un team usa entrambi nel proprio lavoro, deve sapere quale identità e quale configurazione si applichino a ciascuno, soprattutto quando vengono aperti file o sessioni con dati aziendali.

La regola operativa può restare semplice: un nuovo strumento richiede una verifica del suo perimetro prima di ricevere accessi equivalenti a quelli già approvati. Il responsabile decide in base al compito e conserva evidenza delle prove. In questo modo la flessibilità del flusso non diventa una progressiva apertura dell’ambiente a risorse che il progetto non aveva previsto di usare.

Quali errori vanno evitati nella configurazione quotidiana?

Gli errori specifici sono confondere locale con offline, usare credenziali produttive per semplificare un test, aprire tutte le cartelle dopo un blocco e considerare una approvazione come rinuncia permanente ai limiti. Un altro errore è non aggiornare la documentazione del team quando cambia il percorso di esecuzione. Il perimetro deve restare comprensibile anche a chi non ha configurato il primo pilota.

Ogni compito dovrebbe inoltre indicare il risultato atteso e i file che possono essere modificati. Se l’agente propone un intervento fuori da quel perimetro, il responsabile valuta la necessità prima di estenderlo. Questa disciplina rende più semplice leggere il diff e distinguere una correzione pertinente da cambiamenti collaterali che richiedono altre prove. La sandbox aiuta a contenere le operazioni, mentre il mandato mantiene chiaro lo scopo del lavoro.

Non emerge una esclusione italiana dall’annuncio, ma client, versioni e condizioni restano da verificare nella release e nella documentazione applicabile. Per integrare un assistente di sviluppo con accessi coerenti al progetto, il lavoro sul software aziendale può partire da un repository di prova, un compito circoscritto e una verifica concreta dei confini.