Ambiente di prova isolato per il vibe coding: Sandbox, utente separato o container

Vuoi provare il codice generato dall’IA senza rischiare il PC? Windows Sandbox, utente separato o container senza rete: come prepararli passo per passo.

Hai chiesto all’IA uno script che rinomina le foto, uno che «pulisce» una cartella di download o un piccolo server locale. Prima di lanciarlo sul computer dove tieni documenti, password salvate nel browser e chiavi SSH, ti viene un dubbio legittimo: e se fa qualcosa che non ho capito? Nella guida ai rischi del vibe coding consiglio di non eseguire codice generato «a scatola chiusa»; qui ti mostro come costruire la scatola. Un ambiente di prova isolato è un posto dove il codice può sbagliare, cancellare o collegarsi in rete senza toccare i tuoi file veri e i tuoi account.

La risposta breve: su Windows Pro usa Windows Sandbox con la rete spenta; su Windows Home, macOS e Linux crea un utente dedicato senza accesso ai tuoi dati; se ti serve qualcosa di ripetibile su tutti e tre i sistemi, usa un container senza rete con la cartella del progetto in sola lettura. Sotto trovi i tre percorsi completi, con i comandi e cosa fare quando non partono.

ℹ️ Nota / Prerequisito operativo: ti servono un account amministratore sul computer, 20–30 minuti e lo script da provare in una cartella sua (per esempio C:\Users\tuonome\prove\rinomina-foto o /Users/tuonome/prove/rinomina-foto). Se lo script ti chiede chiavi API vere, fermati: in prova si usano chiavi finte o di test.

ℹ️ Nota / Come ho verificato questa guida: il 22 ottobre 2026 ho eseguito davvero i passaggi Linux dell’utente dedicato su Debian 13 (creazione con adduser e useradd, chmod 750, verifica con ls) e ho controllato su macOS 15.7.7 la sintassi di sysadminctl e i permessi predefiniti delle cartelle personali, senza creare utenti sul Mac di lavoro. La parte Windows non l’ho eseguita: il file .wsb è stato verificato elemento per elemento sulla documentazione ufficiale Microsoft (XML ben formato, solo elementi e valori documentati). Anche i comandi docker non li ho potuti lanciare in questa sessione, perché sui due computer di prova Docker non era installato: le opzioni sono quelle documentate in docker run --help e nella documentazione Docker.

Perché il venv non basta

Il venv (ambiente virtuale Python) separa i pacchetti di un progetto da quelli degli altri. È utile, ma non è una barriera di sicurezza: uno script lanciato dentro un venv gira con i permessi del tuo utente, legge la tua cartella Documenti, può cancellare file, aprire connessioni di rete e leggere i cookie del browser se sa dove sono.

Lo stesso vale per pip install: l’installazione di alcuni pacchetti può eseguire codice sul tuo computer già in quella fase, prima ancora che tu lanci lo script. Se il nome del pacchetto l’ha suggerito l’IA e non l’hai verificato, il rischio comincia lì.

Per decidere quale isolamento ti serve, chiediti cosa può andare storto:

Nessuno di questi metodi è una garanzia assoluta: riducono il danno possibile. La regola pratica che uso è semplice: più il codice tocca file, rete o credenziali, più forte deve essere l’isolamento.

Windows: Windows Sandbox con rete spenta

Windows Sandbox è una macchina virtuale usa e getta integrata in Windows. Secondo la documentazione Microsoft su Windows Sandbox, è disponibile su Windows Pro, Enterprise ed Education, non su Windows Home, e richiede la virtualizzazione attiva nel BIOS, almeno 4 GB di RAM (8 consigliati) e due core.

Passo 1 — Attiva la funzionalità

1. Premi Win, scrivi Attiva o disattiva funzionalità di Windows e apri il pannello.
2. Spunta Sandbox di Windows e premi OK.
3. Riavvia quando te lo chiede.

In alternativa, apri PowerShell come amministratore (tasto destro su Start → Terminale (amministratore)) e lancia:

Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online

Se la voce non compare, di solito hai Windows Home (controlla con winver) o la virtualizzazione è spenta nel BIOS.

Passo 2 — Crea il file di configurazione .wsb

Avviata dal menu Start, la Sandbox parte con la rete attiva e con gli appunti condivisi. Per una prova seria serve un file di configurazione. Crea la cartella C:\Users\tuonome\prove\rinomina-foto, mettici lo script, poi crea accanto C:\Users\tuonome\prove\output (vuota). Apri il Blocco note, incolla questo testo sostituendo tuonome, e salvalo come "prova-isolata.wsb" (con le virgolette, così il Blocco note non aggiunge .txt):

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <AudioInput>Disable</AudioInput>
  <VideoInput>Disable</VideoInput>
  <PrinterRedirection>Disable</PrinterRedirection>
  <vGPU>Disable</vGPU>
  <MemoryInMB>4096</MemoryInMB>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Users\tuonome\prove\rinomina-foto</HostFolder>
      <SandboxFolder>C:\progetto</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
    <MappedFolder>
      <HostFolder>C:\Users\tuonome\prove\output</HostFolder>
      <SandboxFolder>C:\output</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

Ogni riga ha un compito preciso:

• Networking Disable: niente rete. Lo script non può scaricare altro né inviare dati. È l’opzione più importante.
• ClipboardRedirection Disable: blocca il copia-incolla tra il tuo Windows e la Sandbox, così un testo copiato per sbaglio (una password, un IBAN) non entra nella prova.
• AudioInput / VideoInput Disable: microfono e webcam restano fuori. Il microfono, di default, è condiviso.
• PrinterRedirection Disable: le stampanti del computer non sono visibili (è già il default; lo scrivo per chiarezza).
• vGPU Disable: niente accesso virtualizzato alla scheda video. Microsoft segnala che la vGPU può aumentare la superficie d’attacco; la grafica diventa più lenta, per uno script non cambia nulla.
• MemoryInMB: RAM assegnata. Sotto i 2048 MB Windows la alza da solo al minimo necessario.
• MappedFolder con ReadOnly true: la cartella del progetto si vede dentro la Sandbox in C:\progetto, ma lo script non può modificarla.
• MappedFolder di output con ReadOnly false: l’unica cartella scrivibile. Le modifiche qui restano dopo la chiusura, quindi controlla cosa contiene prima di aprire i file sul tuo Windows.

Due varianti tipiche. Per una prova che deve scaricare le dipendenze, imposta <Networking>Enable</Networking> solo nella prima sessione, installa, verifica, poi richiudi e torna a Disable. Per una prova «solo lettura» pura, elimina il secondo MappedFolder.

Passo 3 — Avvia, prova, chiudi

1. Fai doppio clic su prova-isolata.wsb. Si apre una finestra con un Windows pulito.
2. Dentro la Sandbox installa Python dal sito ufficiale (con la rete spenta devi prima copiare l’installer nella cartella del progetto, perché gli appunti sono disattivati).
3. Apri Prompt dei comandi nella Sandbox e lancia:

cd C:\progetto
python main.py --output C:\output

4. Chiudi la finestra: Windows chiede conferma ed elimina tutto quello che c’era nella Sandbox.

Hai finito se lo script ha prodotto il risultato atteso in C:\Users\tuonome\prove\output e la cartella del progetto è identica a prima.

Windows Home, macOS e Linux: un utente dedicato

Se la Sandbox non è disponibile, il compromesso più semplice è un secondo account senza privilegi di amministratore: lo script gira lì e non può leggere i file del tuo utente principale, a patto che i permessi della tua cartella personale siano chiusi. La rete resta attiva, quindi non mettere in quell’account credenziali vere.

Windows Home

Da Impostazioni → Account → Altri utenti → Aggiungi account, scegli di non avere le informazioni di accesso della persona e poi di aggiungere un utente senza account Microsoft. Dal terminale (PowerShell come amministratore) ottieni lo stesso risultato:

net user vibelab * /add

L’asterisco fa chiedere la password due volte senza mostrarla. Il nuovo utente è standard (non amministratore). Esci, accedi come vibelab, installa Python e lavora in C:\Users\vibelab\prove. Verifica l’isolamento provando ad aprire C:\Users\tuonome\Documents da quell’account: deve comparire «Accesso negato».

macOS

Apri Impostazioni di Sistema → Utenti e gruppi → Aggiungi utente e crea un utente Standard. Dal Terminale:

sudo sysadminctl -addUser vibelab -fullName "Vibe Lab" -password -

Il trattino finale fa chiedere la password in modo interattivo: è il comportamento documentato nell’aiuto di sysadminctl («Pass ‘-’ instead of password … to request prompt»), che ho controllato su macOS 15.7.7. Per lavorare con quell’utente senza fare logout:

su - vibelab

Controlla poi che non possa leggere i tuoi documenti:

ls /Users/tuonome/Documents

L’output atteso è Permission denied. Su macOS 15.7.7 la cartella Documenti di un utente è creata come drwx------ (solo il proprietario la apre) e la cartella personale come drwxr-x---, quindi un secondo utente standard non ne vede il contenuto. Se vedi l’elenco dei file, i permessi della tua cartella sono stati allargati in passato: correggili con chmod 700 /Users/tuonome/Documents.

Linux

Su Debian e Ubuntu:

sudo adduser vibelab

Su Fedora, Arch e altre distribuzioni:

sudo useradd -m -s /bin/bash vibelab
sudo passwd vibelab

Entra come quell’utente con sudo -iu vibelab. Poi verifica i permessi della tua cartella personale:

ls -ld /home/tuonome

Se la terza terna mostra r-x (per esempio drwxr-xr-x), gli altri utenti possono leggere la tua cartella. Chiudila con:

chmod 750 /home/tuonome

Dopo la modifica, ls /home/tuonome lanciato come vibelab deve rispondere Permission denied. Nel mio test su Debian 13, con la cartella personale in drwxr-xr-x l’utente vibelab ne vedeva l’elenco; dopo chmod 750 il risultato è stato questo:

drwxr-x--- 11 box box 4096 Oct 22 00:06 /home/box
ls: cannot open directory '/home/box': Permission denied

Tutti e tre i sistemi: container senza rete

Un container è un processo isolato con un suo filesystem. Con le opzioni giuste puoi togliergli la rete e dargli solo la cartella del progetto in sola lettura. Serve Docker Desktop (Windows e macOS) o Docker Engine / Podman (Linux). Docker Desktop, secondo il suo contratto di licenza, è gratuito per uso personale, istruzione e piccole aziende sotto i 250 dipendenti e i 10 milioni di dollari di fatturato; oltre serve un abbonamento.

Fase 1 — Installa le dipendenze in un volume (con rete)

La prova vera girerà senza rete, quindi le dipendenze vanno scaricate prima, in un volume separato. Dalla cartella del progetto:

Windows (PowerShell):

cd C:\Users\tuonome\prove\rinomina-foto
docker volume create vibe-deps
docker run --rm -v vibe-deps:/deps -v "${PWD}\requirements.txt:/req.txt:ro" python:3.12-slim python -m pip install --target /deps -r /req.txt

macOS / Linux:

cd ~/prove/rinomina-foto
docker volume create vibe-deps
docker run --rm -v vibe-deps:/deps -v "$PWD/requirements.txt:/req.txt:ro" python:3.12-slim python -m pip install --target /deps -r /req.txt

L’output atteso termina con Successfully installed …. Il codice d’installazione dei pacchetti gira dentro il container, non sul tuo sistema.

Fase 2 — Esegui lo script senza rete

Crea una cartella output dentro il progetto, poi:

Windows (PowerShell):

docker run --rm -it --network none --read-only --tmpfs /tmp --cap-drop ALL --security-opt no-new-privileges --memory 1g --pids-limit 256 -e PYTHONPATH=/deps -v vibe-deps:/deps:ro -v "${PWD}:/progetto:ro" -v "${PWD}\output:/output" -w /progetto python:3.12-slim python main.py --output /output

macOS / Linux:

docker run --rm -it --network none --read-only --tmpfs /tmp --cap-drop ALL --security-opt no-new-privileges --memory 1g --pids-limit 256 --user "$(id -u):$(id -g)" -e PYTHONPATH=/deps -v vibe-deps:/deps:ro -v "$PWD:/progetto:ro" -v "$PWD/output:/output" -w /progetto python:3.12-slim python main.py --output /output

Le opzioni, una per una:

• --rm: elimina il container alla fine. Ogni prova riparte pulita.
• -it: terminale interattivo, utile se lo script fa domande. Toglilo per esecuzioni automatiche.
• --network none: nessuna interfaccia di rete a parte quella locale del container. Lo script non può contattare server esterni.
• --read-only: il filesystem del container è in sola lettura; si scrive solo dove lo permetti tu.
• --tmpfs /tmp: una /tmp scrivibile in memoria, perché molti programmi la usano. Sparisce alla chiusura.
• --cap-drop ALL: toglie al container i privilegi speciali di Linux (modificare la rete, montare dischi e simili).
• --security-opt no-new-privileges: impedisce ai processi di guadagnare privilegi in più durante l’esecuzione.
• --memory 1g e --pids-limit 256: limitano RAM e numero di processi, così un ciclo impazzito non blocca il computer.
• --user "$(id -u):$(id -g)" (macOS/Linux): lo script gira con il tuo numero utente e i file in output restano tuoi, non di root.
• -e PYTHONPATH=/deps: dice a Python di cercare i pacchetti nel volume installato in Fase 1.
• -v …:/progetto:ro: monta il progetto in sola lettura (ro). -v …output:/output è l’unica cartella scrivibile.
• -w /progetto: cartella di lavoro iniziale.

Tre combinazioni che uso spesso: solo --rm --network none -v …:ro per una lettura veloce di uno script che non scrive nulla; la riga completa sopra per script che modificano file; la Fase 1 da sola, quando vuoi solo vedere cosa installa un requirements.txt. L’aiuto completo è in docker run --help.

Errori tipici e come risolverli

• «Sandbox di Windows» non c’è tra le funzionalità → edizione Home o virtualizzazione spenta → controlla winver; su Home passa all’utente dedicato o al container.
• La Sandbox non parte con «No hypervisor was found» → Hyper-V non attivo o un altro hypervisor in uso → attiva la virtualizzazione nel BIOS e la piattaforma Hyper-V.
• Il .wsb dà errore all’avvio → XML non valido o cartella host inesistente → controlla che ogni tag sia chiuso e che HostFolder esista già.
• Errore 0x80070005 (accesso negato) su una cartella mappata → hai mappato direttamente sul Desktop della Sandbox → usa una cartella come C:\progetto.
• Nel container lo script dice ModuleNotFoundError → manca -e PYTHONPATH=/deps o la Fase 1 è fallita → rilancia la Fase 1 e leggi l’ultima riga.
• Read-only file system → lo script scrive nella cartella del progetto → passa il percorso --output /output o adatta lo script.
• Su PowerShell ${PWD} non viene espanso → stai usando il Prompt dei comandi → usa PowerShell, oppure scrivi il percorso completo tra virgolette.
• Lo script funziona solo con la rete → ti serve capire a chi si collega prima di dargli accesso: leggi il codice cercando requests, urllib, http e gli URL, e decidi se fidarti.

Domande Frequenti (FAQ)

Windows Sandbox è disponibile su Windows 11 Home?

No. Secondo la documentazione Microsoft, Windows Sandbox è supportata su Pro, Enterprise ed Education. Su Home le alternative pratiche sono un utente standard dedicato (protegge i tuoi file, non la rete) o un container Docker senza rete, che richiede Docker Desktop con WSL 2.

Una macchina virtuale completa è più sicura della Sandbox?

Offre un isolamento simile e più controllo (snapshot, sistemi diversi, rete configurabile), ma richiede più tempo da preparare e da aggiornare. Per provare uno script ogni tanto, Sandbox o container bastano. Una VM ha senso se fai prove spesso o ti serve un sistema operativo diverso dal tuo.

Il container mi protegge da un pacchetto malevolo?

Riduce molto il danno: senza rete, con progetto in sola lettura e senza privilegi extra, il pacchetto vede solo ciò che gli hai montato. Non è una garanzia: i container condividono il kernel del sistema e una falla del motore può superarli. Per codice di cui sospetti seriamente, preferisci una VM separata.

Posso lasciare la rete attiva nella Sandbox per comodità?

Puoi, ma perdi la protezione più utile: con la rete attiva lo script può scaricare altro codice o inviare dati. Microsoft stessa avvisa che la rete attiva espone le applicazioni non fidate alla rete interna. Accendila solo per installare le dipendenze, poi spegnila.

Devo rifare tutto per ogni prova?

No. Il file .wsb si riusa: cambi solo HostFolder. Il volume vibe-deps resta finché non lo elimini con docker volume rm vibe-deps; se cambi progetto, crea un volume con un nome diverso per non mescolare le dipendenze. Dentro la Sandbox, invece, Python va reinstallato a ogni avvio: tieni l’installer nella cartella del progetto.

Dopo la prova posso fidarmi del codice?

Hai solo visto cosa fa in quel caso. Prima di usarlo sui dati veri leggilo almeno nei punti che toccano file, rete e credenziali: la code review umana in 15 minuti ti dà l’ordine da seguire.

Dove finisce la prova e dove inizia l’uso vero

Un ambiente isolato non rende sicuro il codice: ti permette di vederlo sbagliare senza conseguenze. Il passo successivo resta la lettura del codice e, per i progetti che crescono, un prompt di avvio con vincoli di sicurezza che eviti molti problemi a monte. Per il quadro completo su cosa può andare storto con il codice scritto dall’IA, torna all’articolo madre sui rischi del vibe coding che non vedi.