Repo del giorno: clawk, una VM usa-e-getta per far correre gli agenti di coding

🔍 Cos'è clawk: la terza via tra babysitting e full-auto incosciente

clawk è una CLI scritta in Go (Apache-2.0, macOS 14+ su Apple silicon; Linux via firecracker, sperimentale) che costruisce attorno all'agente una macchina separata: la VM esegue un suo kernel Linux, il filesystem dell'host non è nascosto da regole di deny — semplicemente non è mai stato montato. Dentro il guest l'agente è root: installa pacchetti, avvia database e dev server, esegue build non fidate a piena velocità.

La parte che considero più interessante è la scelta dichiarata sul full-auto: nei sandbox i runner partono nelle loro modalità «externally sandboxed» — Claude Code con `--dangerously-skip-permissions`, Codex con `--dangerously-bypass-approvals-and-sandbox`. Sulla macchina vera quei flag sarebbero incoscienti; qui sono il punto: il contenimento lo fanno il confine della VM e la allow-list di rete, non le conferme a ogni comando. E chi le vuole comunque ha l'opzione `--safe`.

repo       clawkwork/clawk
linguaggio Go 1.26+ · licenza Apache-2.0 · v0.2.0 (13 luglio 2026)
piattaforma macOS 14+ Apple silicon · Linux (firecracker, sperimentale)
cosa       VM Linux usa-e-getta per Claude Code, Codex o shell
come       Virtualization.framework, rootfs da immagini OCI, no Docker
rete       deny-by-default con allow-list DNS-aware e log dei denial

⚙️ Come funziona: un comando, una VM, la rete filtrata sotto il guest

Il flusso quotidiano è ridotto all'osso: `cd` nel repo e `clawk` — la prima volta costruisce il rootfs da un'immagine OCI qualsiasi (la scarica e la converte in disco ext4 da sola, senza demone Docker), dai boot successivi si parte in pochi secondi grazie ai cloni copy-on-write. Il repo è montato live via virtio-fs, quindi il worktree che l'agente modifica è lo stesso aperto nel tuo editor.

La rete è il pezzo di ingegneria che mi ha convinto a segnalarlo: l'intero livello L3 della VM — gateway, DHCP, DNS, NAT — è uno stack TCP/IP userspace dentro il daemon sull'host. Ogni connessione in uscita e ogni risposta DNS consultano la allow-list lì, dove nemmeno root dentro il guest può toccarla: i registri comuni (npm, PyPI, GitHub, Anthropic) sono pre-consentiti, tutto il resto è rifiutato e finisce nel log dei denial. Le chiavi SSH non entrano mai nella VM: l'ssh-agent dell'host viene inoltrato, così `git push` funziona ma la firma resta fuori.

cd ~/code/mio-progetto
clawk                    # boot della VM + Claude Code già collegato
clawk run codex          # stesso sandbox, altro agente (o shell)
clawk network denials    # cosa ha provato a contattare ed è stato bloccato
clawk forward add mio-progetto 3000   # dev server del guest su localhost:3000
clawk down               # stop: repo e conversazioni persistono
clawk destroy && clawk   # VM devastata? Se ne ricrea una pulita

🧰 Configurazione e ticket mode: un sandbox per progetto, o per attività

Di default non serve alcun file di configurazione; quando un progetto chiede di più si scrive un `clawk.mod` in sintassi stile go.mod: CPU e memoria, l'immagine OCI da usare come rootfs, gli host extra da consentire, le porte da inoltrare, gli hook `on create` e persino istruzioni per l'agente. Il blocco viene fotografato alla creazione del sandbox, così un ambiente in esecuzione non cambia mai sotto i piedi.

Sopra ci sono i comfort che trasformano una VM in un flusso di lavoro: `clawk snapshot` iberna il guest (RAM salvata su disco, dev server compresi) e il boot successivo riprende esattamente da lì; il ticket mode crea con `clawk work TICKET-123` un sandbox con un git worktree per repo su branch dedicati, e `clawk pr` apre PR incrociate per ciò che è cambiato. Le conversazioni di Claude e Codex sono montate dall'host, quindi sopravvivono anche al `destroy` e si riprendono con `--resume`.

sandbox mio-progetto (
    vm (
        cpu    4
        memory 8GiB
        image  golang:1.25      # qualunque immagine OCI
    )
    network ( allow api.example.com )
    forwards ( 3000 )
    on create ( "go mod download" )
)

🏢 Perché è interessante, per sviluppatori e PMI

Per chi sviluppa, clawk risolve il collo di bottiglia vero del vibe coding: la produttività degli agenti crolla se ogni comando aspetta una conferma, ma l'alternativa — piena autonomia sulla macchina di lavoro — espone file personali, credenziali e chiavi. Spostare il confine dal prompt all'hypervisor cambia la natura del rischio: un `rm -rf` sbagliato costa un `clawk destroy && clawk`, non un pomeriggio di ripristini. E rispetto a container e devcontainer c'è una differenza strutturale: quelli condividono il kernel dell'host e vedono il filesystem meno le regole di deny; qui il kernel è un altro e l'host non è mai stato montato.

Per una PMI che adotta agenti nei processi di sviluppo, i due log di clawk valgono quanto l'isolamento: `clawk network denials` è l'elenco, per hostname, di ciò che l'agente ha provato a contattare ed è stato bloccato — esattamente il tipo di visibilità di cui ho scritto parlando di governance e shadow AI. E il `clawk.mod` versionato nel repo è una policy eseguibile: stessa VM, stessa allow-list e stesse porte per tutti, sviluppatori e agenti. Il progetto stesso, va detto, è onesto sui limiti: ciò che monti e ciò che metti in allow-list è esposto — github.com è pre-consentito e l'ssh-agent inoltrato può pushare — quindi il codice che esce da un sandbox va revisionato come la PR di uno sconosciuto.

⚠️ I limiti da conoscere prima di adottarlo

Il progetto è dichiaratamente pre-1.0: v0.2.0 del 13 luglio, breaking change attesi tra le release e una manciata di stelle su GitHub — l'ho scelto per la qualità del design documentato (ARCHITECTURE.md e DESIGN.md sono tra i più curati che abbia letto ultimamente), non per la trazione, che è tutta da costruire. Vale il principio di sempre: una segnalazione è un punto di partenza per una valutazione, non una due diligence già fatta.

Anche il perimetro tecnico va conosciuto: serve un Mac Apple silicon con macOS 14+ (niente Intel, niente Windows; su Linux il provider firecracker è sperimentale), e la sicurezza si ferma dove la configuri tu — segreti passati alla VM sono leggibili dall'agente, e le protezioni si fondano sull'isolamento di Virtualization.framework, senza difese aggiuntive contro escape dell'hypervisor.

• Pre-1.0 e giovanissimo: pubblicato a inizio luglio 2026, breaking change dichiarati tra le release.
• Solo Apple silicon (macOS 14+) come piattaforma stabile; Linux/firecracker sperimentale, Windows assente.
• Ciò che monti è esposto: worktree scrivibile e ssh-agent inoltrato — la review del codice in uscita resta tua.
• Non protegge dai segreti condivisi: env e file passati al sandbox sono leggibili (e inviabili verso host in allow-list).

✅ Da dove partire

Il percorso che suggerisco: `brew install clawkwork/tap/clawk`, poi un `clawk` dentro un progetto non critico per prendere confidenza con il ciclo boot → lavoro → `down` → `attach`. Dedica cinque minuti a `clawk network denials` dopo la prima sessione: vedere che cosa l'agente ha provato a contattare è istruttivo di suo. Poi scrivi il `clawk.mod` del progetto — immagine, host consentiti, porte — e committalo, così l'ambiente dell'agente viaggia con il repo.

Nel quadro più ampio, clawk completa la scala di contenimento di cui ho scritto nelle ultime settimane: i guardrail sui comandi filtrano le intenzioni, le sandbox di processo limitano un singolo programma, e una VM usa-e-getta sposta l'intero carico di lavoro su una macchina che non è la tua. Anche Anthropic sta investendo sulla stessa direzione con il sandboxing nativo di Claude Code: il messaggio comune è che l'autonomia degli agenti si concede per architettura, non per fiducia.

Altri articoli del blog