Docker Sandbox è lo strumento di Docker che fa girare un agente AI di programmazione, come Claude Code o Codex, dentro una microVM isolata: l'agente vede solo la cartella del progetto, ha un suo kernel e un suo Docker, ed esce su internet solo verso i siti che autorizzi. In locale è gratis, anche per lavoro commerciale.
Dal 24 settembre 2026 esiste anche la versione cloud, a pagamento al secondo, per lasciare l'agente al lavoro quando chiudi il portatile.
In questa guida ti spiego cos'è Docker Sandbox, come si installa, quanto costa la parte cloud con esempi di calcolo e quando secondo me conviene usarlo.
Lavoro ogni giorno con agenti AI su codice di clienti: la domanda che mi faccio sempre è cosa può toccare l'agente se qualcosa va storto. Docker Sandbox è una risposta concreta a questa domanda.
Cos'è Docker Sandbox e perché non è un semplice container
Un container normale condivide il kernel del tuo computer. Se l'agente deve usare Docker (per fare una build o lanciare docker compose), di solito gli dai accesso al demone Docker dell'host. A quel punto vede tutti i tuoi container, compresi database e servizi che non c'entrano con il progetto.
Docker Sandbox risolve il problema con un confine diverso:
- MicroVM dedicata: ogni sandbox ha un suo kernel, non quello del tuo sistema.
- Demone Docker privato: l'agente può fare build e avviare container, ma solo dentro la sua VM. Sul tuo host non compaiono.
- Solo la cartella di lavoro: il resto del disco, Desktop compreso, non esiste per l'agente.
- Rete filtrata: un proxy decide quali domini sono raggiungibili.
- Segreti iniettati dal proxy: l'agente usa le credenziali senza vederle in chiaro, il che limita i danni di un prompt injection.
Le prime versioni si lanciavano con docker sandbox run dentro Docker Desktop. Oggi lo strumento è una CLI separata, sbx, e non serve più né Docker Desktop né Docker Engine.
Differenza tra Docker container e Docker sandbox
In breve: il container nasce per impacchettare e distribuire applicazioni di cui ti fidi. La sandbox nasce per far girare codice autonomo di cui non ti fidi del tutto. Il container è più leggero e parte prima; la sandbox aggiunge un confine a livello di hypervisor, che è quello che serve quando è un modello a decidere quali comandi eseguire.
Quali agenti AI supporta Docker Sandbox
La documentazione ufficiale elenca integrazioni pronte per Claude Code, Codex, GitHub Copilot, Cursor, Devin, Docker Agent, Droid, Gemini, Kiro, OpenCode e una shell generica. Per la versione cloud, al lancio Docker indica kit già pronti per Claude Code, Codex, Copilot, Antigravity, OpenCode e Hermes, più la possibilità di crearne di propri.
Il modello resta quello del tuo abbonamento o della tua API key: Docker non ti vende i token. Se usi Claude Code con un piano Max, Team o Enterprise, dentro la sandbox fai /login e il token di sessione resta sul tuo host, non viene salvato nella sandbox.
Requisiti di sistema di Docker Sandbox
- macOS: Sonoma 14 o successivo, solo Apple silicon.
- Windows: Windows 11 a 64 bit, con Windows Hypervisor Platform attivo.
- Linux: Ubuntu 24.04 o successivo, con virtualizzazione KVM.
Per le sandbox cloud serve una versione recente della CLI (0.45 o successiva) e un piano Docker Personal o Pro con pagamento a consumo attivo.
Come installare Docker Sandbox e lanciare Claude Code
Ecco la procedura che seguirei su una macchina nuova. Se non hai ancora Claude Code, parti dalla mia guida su come installare Claude Code.
1. Installa la CLI sbx
Su macOS:
brew trust docker/tap
brew install docker/tap/sbx
Su Windows (utente corrente):
winget install -h Docker.sbx
Su Ubuntu:
curl -fsSL https://get.docker.com | sudo SBX=1 sh
2. Accedi al tuo account Docker
sbx login
Si apre il browser per il login OAuth.
3. Avvia l'agente nella cartella del progetto
cd ~/mio-progetto
sbx run --name mio-progetto claude
Al posto di claude puoi scrivere codex, gemini o un altro agente supportato. Al primo avvio ti chiede il profilo di rete.
4. Scegli il profilo di rete
- Open: tutto il traffico è permesso.
- Balanced: blocca tutto tranne i siti comuni di sviluppo (registri di pacchetti, GitHub, API dei modelli). È il punto di partenza consigliato.
- Locked Down: blocca tutto finché non autorizzi tu.
Controlli le regole con sbx policy ls e apri un dominio con sbx policy allow network nomedominio.
5. Passa i segreti nel modo giusto
Invece di copiare token in un file .env dentro il progetto, li registri con la CLI. Per GitHub, per esempio:
sbx secret set github --command 'gh auth token'
6. Ferma o elimina la sandbox
sbx stop mio-progetto
sbx rm mio-progetto
stop conserva lo stato, rm cancella tutto quello che c'è dentro la sandbox ma non tocca i file sul tuo computer.
Attenzione: la cartella del progetto è in scrittura
Questo è il punto che molti sottovalutano. Se non indichi altro, la cartella corrente viene montata in lettura e scrittura: l'agente e il tuo sistema vedono gli stessi file.
È comodo, perché le modifiche compaiono subito come diff da rivedere prima del commit. Però significa che Docker Sandbox protegge il resto del computer, non il progetto stesso.
Se vuoi che l'agente lavori su una copia, usa la modalità clone, che gli dà un clone privato del repository. Io la userei per i lavori lunghi e non presidiati, tipo un Ralph Loop lasciato girare di notte.
Docker Cloud Sandboxes: cosa cambia dal 24 settembre 2026
Con le Cloud Sandboxes la stessa Docker sandbox gira sull'infrastruttura di Docker. Stessa CLI, stesse regole, stesso isolamento a microVM. L'avvio dichiarato è nell'ordine di poche centinaia di millisecondi e le risorse vanno da 1 a 16 vCPU.
I comandi principali:
sbx --cloud run claude
sbx --cloud ls
sbx --cloud attach nome-sandbox
sbx move mio-progetto --to cloud
L'ultimo comando è il più interessante: sposta una sandbox dal portatile al cloud (e anche al contrario) portandosi dietro il filesystem. Inizi un lavoro in locale, lo sposti, chiudi il computer e l'agente continua.
Durata delle sessioni
Una Docker sandbox in cloud dura un'ora di default. Puoi impostare una durata diversa e cosa fare alla scadenza (fermarla, riavviarla o eliminarla):
sbx --cloud create --ttl 2h --on-timeout delete claude
Il tetto massimo è 24 ore dalla creazione.
Due limiti da sapere prima
- Le credenziali configurate in locale non sono disponibili nelle sandbox cloud: vanno impostate di nuovo.
- La creazione in cloud non accetta un percorso di lavoro locale: i file li porti con
sbx moveosbx --cloud cp.
Docker Sandbox è gratis? Prezzi reali
Le sandbox locali sono gratuite, anche per uso commerciale. Le sandbox cloud si pagano a consumo, al secondo, in dollari. I costi del modello (Anthropic, OpenAI, Google) restano separati.
| Taglia | vCPU | Memoria | Costo orario |
|---|---|---|---|
| Micro | 1 | 2 GiB | 0,07 $ |
| Small (default) | 2 | 4 GiB | 0,14 $ |
| Medium | 4 | 8 GiB | 0,28 $ |
| Large | 8 | 16 GiB | 0,56 $ |
| XL | 16 | 32 GiB | 1,12 $ |
Sono gratuiti volumi, traffico in uscita, hosting di immagini pubbliche e kit. I nuovi account ricevono 250 $ di credito per le Cloud Sandboxes.
Quanto spendi davvero: tre esempi
- Un agente Small per 8 ore: 1,12 $ al giorno. Su 22 giorni lavorativi fanno 24,64 $ al mese.
- Una sessione XL al massimo della durata (24 ore): 26,88 $.
- Il credito iniziale: 250 $ bastano per circa 1.785 ore di sandbox Small, oppure circa 223 ore di XL.
Nella pratica, quasi sempre il costo vero resta quello dei token del modello, non della macchina. Se vuoi tenere sotto controllo anche quelli, ho scritto una guida al prompt caching per ridurre i costi API.
I Kit: agente, strumenti e regole in un'unica immagine
Insieme al cloud, Docker ha presentato la nuova generazione dei Kit. Un Kit impacchetta l'agente, i suoi strumenti e le regole di accesso in un'unica immagine OCI, lo stesso standard dei container. Niente formato proprietario: le regole viaggiano dentro il Kit e valgono ovunque lo lanci. Docker ha dichiarato che proporrà la specifica alla Cloud Native Computing Foundation.
Per chi lavora in team è il pezzo più utile: definisci una volta cosa può fare l'agente (domini permessi, server MCP collegati, strumenti installati) e tutti partono dalla stessa base.
Claude Code in Docker Sandbox: il nodo della configurazione
Un difetto segnalato spesso dagli utenti nei forum ufficiali: dentro la sandbox l'agente gira come un utente separato, con la sua cartella home. Le tue skill, i plugin, gli hook e il CLAUDE.md personale che hai sul computer non vengono ripresi in automatico.
La soluzione documentata è preparare un template (oggi un Kit) con la tua configurazione già dentro.
Il mio consiglio: tieni le regole importanti nel CLAUDE.md del progetto, che sta nella cartella montata e quindi l'agente lo vede sempre. Se non sai quali abitudini valgono davvero, parti dalle best practice di Claude Code.
Quando conviene usare Docker Sandbox
Io la vedo così:
- Sì, sempre, se lasci l'agente in modalità autonoma senza approvare ogni comando.
- Sì, se lavori su repository di clienti o su un computer dove ci sono altri progetti, chiavi SSH e credenziali cloud.
- Sì, se installi dipendenze npm o pip scelte dall'agente. Worm come Shai-Hulud passano proprio da lì.
- Sì, se usi plugin e server MCP di terze parti: una falla come Plugin4Shell, la zero-click di Claude Code e Codex, fa molti meno danni se l'agente vive in una VM.
- Forse no, per un task breve e presidiato in cui approvi ogni comando: il permesso manuale dell'agente può bastare.
Locale o cloud?
Locale per il lavoro di tutti i giorni: costa zero e la latenza è quella del tuo computer.
Cloud quando il lavoro dura ore, quando vuoi più agenti in parallelo senza fondere il portatile, o quando ti serve una porta pubblica per mostrare un'anteprima (con sbx --cloud ports nome-sandbox --publish 8080 ottieni un URL HTTPS, ma l'autenticazione la devi mettere tu nel servizio).
Se ti serve un ambiente isolato dentro una tua applicazione, e non per lo sviluppo, valuta anche soluzioni come Vercel Sandbox, che nascono per eseguire codice generato dagli utenti via SDK.
Docker Sandbox per una PMI: cosa controllare
Se in azienda qualcuno usa agenti AI sul codice, tre domande da porsi:
- Dove girano i dati? In locale il codice resta sul computer. In cloud finisce sull'infrastruttura di Docker: se il repository contiene dati personali di clienti, va valutato come qualsiasi fornitore cloud ai fini GDPR.
- Chi decide le regole? Gli amministratori con un abbonamento dedicato possono gestire in modo centralizzato rete, filesystem e policy MCP delle sandbox locali di tutti gli sviluppatori.
- Le chiavi API sono protette? Le chiavi rubate sono il bottino preferito, come racconto nel threat report di Anthropic. Con i segreti iniettati dal proxy l'agente non li legge mai.
Se stai portando agenti AI nei processi della tua azienda e vuoi impostarli in modo sicuro fin dall'inizio, è il lavoro che faccio con l'automazione AI per le imprese. Per un caso specifico puoi scrivermi dalla pagina contatti.
In sintesi
- Docker Sandbox isola gli agenti AI in una microVM con kernel e Docker propri.
- In locale è gratis, si installa con la CLI
sbxe non richiede Docker Desktop. - La cartella del progetto è montata in scrittura: per i lavori lunghi usa la modalità clone.
- Le Cloud Sandboxes costano da 0,07 $ l'ora, con 250 $ di credito iniziale e sessioni fino a 24 ore.
- I Kit trasformano agente e regole in un'immagine OCI condivisibile nel team.



