vibebox

• entrare/collegarsi in secondi: vibebox ti porta in una sandbox riutilizzabile per il repo corrente
• scopo per progetto di default: mount espliciti + modifiche confinate al repo (repo-first, tutto il resto è in allowlist)
• sessionizzato: multi-istanza + gestione delle sessioni (riutilizzo, terminali multipli, pulizia)

Dimostrazione rapida

Quello che dovresti vedere (approssimativamente):

Perché ho costruito VibeBox

Uso agenti di codifica ogni giorno e volevo dare loro una shell reale senza consegnare la mia macchina host. Se restringi le maglie, ottieni continue conferme; se allenti le briglie, ti preoccupi di cancellare file, toccare segreti o uscire dal repo.

VibeBox è la via di mezzo: una sandbox per repo con un confine VM rigido, rientro rapido e mount espliciti. È costruita per essere "sempre attiva" per il lavoro degli agenti, senza trasformare la sicurezza in una seccatura.

Perché una micro-VM (invece dei container)?

I container sono fantastici. VibeBox non cerca di sostituire Docker/devcontainer per la creazione di servizi.

Volevo specificamente un'impostazione predefinita a forma di VM per i flussi di lavoro degli agenti su macOS:

• confine di isolamento a livello di kernel guest di default: quando lascio che un agente esegua comandi arbitrari, voglio che la "modalità sicura" sia un guest Linux, non il mio host.
• sessioni come flusso di lavoro di prima classe: collegamento/riutilizzo per repo, più terminali nella stessa sandbox, pulizia affidabile per evitare ambienti orfani.
• elenchi di mount espliciti come esperienza utente principale: per repo di default; tutto il resto è una decisione esplicita.
• configurazione minima per repo: puoi anche riprodurre parti di questo con compose/devcontainer, ma volevo un singolo comando che funzioni da repo a repo senza mantenere configurazioni di container per il flusso di lavoro base di "shell sicura".

Confronto

Ecco perché non ho semplicemente usato opzioni esistenti:

• vibe: super comodo e azzecca "zero-config, basta andare". VibeBox è intenzionalmente su un asse diverso: config per repo
  • sessioni + ciclo di vita multi-istanza.
• QEMU: potente, ma la superficie di configurazione è enorme. Per la sandbox quotidiana non è "apri un repo e vai" — è un progetto a sé.
• Docker / devcontainer / devpods: grande ecosistema. La mia frizione non era il tempo di avvio grezzo, ma l'overhead quotidiano di mantenere sandbox per agente per repo sicure di default (allowlist di mount, esposizione di segreti, collegamento/riutilizzo, pulizia) senza mantenere config di container per repo per il flusso di lavoro base.

Ecco cosa mi ha spinto a costruire VibeBox: volevo una sandbox per progetto facile da avviare (basta vibebox), che supporti configurazione reale + sessioni e mantenga un confine di isolamento rigido.

Installazione

Requisiti

• macOS su Apple Silicon (VibeBox utilizza le API di virtualizzazione di Apple).

Prima esecuzione

La prima esecuzione di vibebox scarica un'immagine base Debian e la prepara. Successivamente, le istanze per progetto riutilizzano l'immagine base in cache per avvii molto più rapidi.

Documentazione

Avvio rapido

Al primo avvio, VibeBox crea vibebox.toml nel tuo progetto (se mancante) e una directory .vibebox/ per i dati dell'istanza.

Configurazione (vibebox.toml)

vibebox.toml risiede nella radice del tuo progetto di default. Puoi sovrascriverlo con vibebox -c percorso/di/vibebox.toml o la variabile d'ambiente VIBEBOX_CONFIG_PATH, ma il percorso deve rimanere all'interno della directory del progetto.

Configurazione di default (creata automaticamente quando mancante):

disk_gb viene applicato solo quando il disco dell'istanza viene creato per la prima volta. Se lo modifichi in seguito, esegui vibebox reset per ricreare il disco.

Mount

• Il tuo progetto viene montato in lettura/scrittura su ~/<nome-progetto> e la shell parte da lì.
• Se esiste una directory .git, viene mascherata con un mount tmpfs all'interno della VM per scoraggiare modifiche accidentali dal guest.
• I mount aggiuntivi provengono da box.mounts con il formato host:guest[:read-only|read-write].
• I percorsi host supportano l'espansione di ~. I percorsi guest relativi vengono trattati come /root/<percorso>.
• I percorsi guest che usano ~ vengono collegati in /home/<ssh-user> per comodità. Esegui vibebox explain per vedere le mappature host/guest risolte.

Comandi CLI

All'interno della VM

• Utente SSH predefinito: vibecoder
• Hostname: vibebox
• Il provisioning dell'immagine base installa: strumenti di build, git, curl, ripgrep, openssh-server e sudo.
• Al primo login, VibeBox installa mise e configura strumenti come uv, node, @openai/codex e @anthropic-ai/claude-code (al meglio).
• Alias di shell: :help e :exit.

Stato e cache

• Lo stato del progetto risiede in .vibebox/ (disco dell'istanza, chiavi SSH, log, socket/pid del manager). vibebox reset lo rimuove.
• La cache globale risiede in ~/.cache/vibebox (immagine base + cache guest condivisa). vibebox purge-cache la cancella.
• L'indice delle sessioni risiede in ~/.vibebox/sessions e viene mostrato da vibebox list.

Contributi

Se sei interessato a contribuire a VibeBox, per favore leggi la nostra documentazione per contributori prima di inviare una pull request.

FAQ

In cosa si differenzia dalle altre sandbox?

VibeBox è progettato per sandbox locali veloci e ripetibili con il minimo overhead. Cosa lo rende diverso:

• Il rientro a caldo è tipicamente <5 secondi sul mio M3 (varia in base a macchina/cache), così puoi tornare subito dentro.
• Un singolo comando semplice — vibebox — ti porta nella sandbox dal tuo progetto.
• La configurazione risiede in vibebox.toml, dove puoi impostare CPU, RAM, dimensione del disco e mount.
• Le sessioni sono di prima classe: riutilizzo, terminali multipli, pulizia.

Ringraziamenti speciali

vibe di lynaghk.

E la fantastica community di Rust — senza l'ecosistema e la toolchain come crates.io, questo non sarebbe stato possibile!

Seguimi su X x.com/robcholz