vibebox

• entrar/anexar em segundos: vibebox coloca você em um sandbox reutilizável para o repositório atual
• escopo por projeto por padrão: montagens explícitas + alterações contidas no repositório (repositório primeiro, todo o resto é permitido)
• sessões: multi-instância + gerenciamento de sessões (reutilização, múltiplos terminais, limpeza)

Demonstração rápida

O que você deve ver (aproximadamente):

Por que construí o VibeBox

Eu uso agentes de codificação diariamente e queria dar a eles um shell real sem entregar minha máquina host. Restringir demais gera confirmações sem parar; afrouxar e você se preocupa em deletar arquivos, tocar em segredos ou sair do repositório.

VibeBox é o meio-termo: um sandbox por repositório com uma fronteira rígida de VM, reentrada rápida e montagens explícitas. Foi construído para ficar "sempre ligado" para trabalho de agente sem tornar segurança uma tarefa chata.

Por que uma micro-VM (vs contêineres)?

Contêineres são ótimos. VibeBox não tenta substituir Docker/devcontainers para construir serviços.

Eu especificamente queria um formato de VM padrão para fluxos de trabalho de agente no macOS:

• isolamento por kernel convidado por padrão: quando deixo um agente executar comandos arbitrários, quero que o "modo seguro" seja um convidado Linux, não meu host.
• sessões como fluxo de trabalho de primeira classe: anexar/reutilizar por repositório, múltiplos terminais no mesmo sandbox, limpeza confiável para evitar ambientes órfãos.
• listas de permissão de montagem explícitas como UX principal: escopo do repositório por padrão; qualquer outra coisa é uma decisão explícita.
• configuração mínima por repositório: você pode reproduzir partes disso com compose/devcontainers, mas eu queria um único comando que funcionasse de repositório em repositório sem manter configurações de contêiner para o fluxo de trabalho básico de "shell seguro".

Comparação

Aqui está o motivo pelo qual simplesmente não usei opções existentes:

• vibe: super conveniente e acerta "configuração zero, só vai". O VibeBox está intencionalmente em um eixo diferente: configuração por repositório + sessões + ciclo de vida multi-instância.
• QEMU: poderoso, mas a superfície de configuração é enorme. Para sandboxing diário não é "abrir um repositório e ir" — é um projeto por si só.
• Docker / devcontainers / devpods: ótimo ecossistema. Minha dificuldade não era o tempo de inicialização bruto, era a sobrecarga diária de manter sandboxes de agente por repositório seguros por padrão (listas de permissão de montagem, exposição de segredos, anexar/reutilizar, limpeza) sem manter configurações de contêiner por repositório para o fluxo de trabalho básico.

Foi isso que me levou a construir o VibeBox: eu queria um sandbox por projeto que fosse rápido de entrar (apenas vibebox), suportasse configuração real + sessões e mantivesse uma fronteira rígida de isolamento.

Instalação

Requisitos

• macOS no Apple Silicon (VibeBox usa as APIs de virtualização da Apple).

Primeira execução

A primeira execução de vibebox baixa uma imagem base Debian e a prepara. Depois disso, as instâncias por projeto reutilizam a imagem base em cache para inicializações muito mais rápidas.

Documentação

Início rápido

Na primeira execução, o VibeBox cria vibebox.toml no seu projeto (se ausente) e um diretório .vibebox/ para dados da instância.

Configuração (vibebox.toml)

vibebox.toml reside na raiz do seu projeto por padrão. Você pode substituí-lo com vibebox -c caminho/para/vibebox.toml ou a variável de ambiente VIBEBOX_CONFIG_PATH, mas o caminho deve permanecer dentro do diretório do projeto.

Configuração padrão (criada automaticamente quando ausente):

disk_gb só é aplicado quando o disco da instância é criado pela primeira vez. Se você alterá-lo depois, execute vibebox reset para recriar o disco.

Montagens

• Seu projeto é montado como leitura-escrita em ~/<nome-do-projeto>, e o shell inicia lá.
• Se existir um diretório .git, ele é mascarado com uma montagem tmpfs dentro da VM para desencorajar edições acidentais do convidado.
• Montagens extras vêm de box.mounts com o formato host:convidado[:somente-leitura|leitura-escrita].
• Caminhos do host suportam expansão de ~. Caminhos relativos do convidado são tratados como /root/<caminho>.
• Caminhos do convidado que usam ~ são vinculados em /home/<ssh-user> para conveniência. Execute vibebox explain para ver os mapeamentos resolvidos host/convidado.

Comandos CLI

Dentro da VM

• Usuário SSH padrão: vibecoder
• Nome do host: vibebox
• A preparação da imagem base instala: ferramentas de compilação, git, curl, ripgrep, openssh-server e sudo.
• No primeiro login, o VibeBox instala mise e configura ferramentas como uv, node, @openai/codex e @anthropic-ai/claude-code (melhor esforço).
• Aliases de shell: :help e :exit.

Estado e Cache

• O estado do projeto reside em .vibebox/ (disco da instância, chaves SSH, logs, socket/pid do gerenciador). vibebox reset o remove.
• O cache global reside em ~/.cache/vibebox (imagem base + cache compartilhado do convidado). vibebox purge-cache o limpa.
• O índice de sessões reside em ~/.vibebox/sessions e é mostrado por vibebox list.

Contribuindo

Se você tem interesse em contribuir para o VibeBox, por favor leia nosso guia de contribuição antes de enviar um pull request.

FAQ

Como isso é diferente de outros sandboxes?

O VibeBox foi construído para sandboxes locais rápidos e repetíveis com o mínimo de cerimônia. O que é diferente aqui:

• A reentrada a quente normalmente leva <5s no meu M3 (varia conforme máquina/cache), então você pode voltar rapidamente.
• Um comando simples — vibebox — coloca você no sandbox a partir do seu projeto.
• A configuração reside em vibebox.toml, onde você pode definir CPU, RAM, tamanho do disco e montagens.
• Sessões são de primeira classe: reutilização, múltiplos terminais, limpeza.

Agradecimentos especiais

vibe por lynaghk.

E a incrível comunidade Rust — sem o ecossistema e as ferramentas como crates.io, isso não seria possível!

Siga-me no X x.com/robcholz