vibebox

• entrar/conectarse en segundos: vibebox te lleva a un sandbox reutilizable para el repo actual
• limitado al proyecto por defecto: montajes explícitos + cambios contenidos en el repo (repo primero, todo lo demás se permite en lista blanca)
• sesionado: multi-instancia + gestión de sesiones (reutilización, múltiples terminales, limpieza)

Demostración rápida

Lo que deberías ver (aproximadamente):

Por qué construí VibeBox

Uso agentes de codificación a diario y quería darles un shell real sin entregarles mi máquina anfitriona. Si cierras todo, recibes confirmaciones constantes; si lo aflojas, te preocupas por borrar archivos, tocar secretos o salir del repo.

VibeBox es el punto medio: un sandbox por repo con un límite duro de VM, reentrada rápida y montajes explícitos. Está construido para estar "siempre encendido" para el trabajo de agentes sin convertir la seguridad en una molestia.

Por qué una micro-VM (vs contenedores)

Los contenedores son geniales. VibeBox no intenta reemplazar Docker/devcontainers para construir servicios.

Específicamente quería un entorno por defecto en forma de VM para flujos de trabajo de agentes en macOS:

• límite de aislamiento del kernel invitado por defecto: cuando dejo que un agente ejecute comandos arbitrarios, quiero que el "modo seguro" sea un invitado Linux, no mi anfitrión.
• sesiones como flujo de trabajo de primera clase: conectar/reutilizar por repo, múltiples terminales en el mismo sandbox, limpieza fiable para evitar entornos huérfanos.
• listas de montaje explícitas como UX principal: limitado al repo por defecto; cualquier otra cosa es una decisión explícita.
• configuración mínima por repo: puedes reproducir partes de esto con compose/devcontainers, pero quería un solo comando que funcione de repo a repo sin mantener configuraciones de contenedor para el flujo de trabajo básico de "shell seguro".

Comparación

Esto es por qué no usé simplemente las opciones existentes:

• vibe: súper conveniente y clava "cero-config, solo ve". VibeBox está intencionadamente en un eje diferente: configuración por repo + sesiones + ciclo de vida multi-instancia.
• QEMU: potente, pero la superficie de configuración es enorme. Para sandboxing diario no es "abrir un repo y listo" — es un proyecto en sí mismo.
• Docker / devcontainers / devpods: gran ecosistema. Mi fricción no fue el tiempo de arranque bruto, fue la sobrecarga diaria de mantener sandboxes de agentes por repo seguros por defecto (listas de montaje, exposición de secretos, conectar/reutilizar, limpieza) sin mantener configuraciones de contenedor por repo para el flujo de trabajo básico.

Eso es lo que me empujó a construir VibeBox: quería un sandbox por proyecto que sea rápido de entrar (solo vibebox), soporte configuración real + sesiones, y mantenga un límite de aislamiento duro.

Instalación

Requisitos

• macOS en Apple Silicon (VibeBox usa las API de virtualización de Apple).

Primera ejecución

La primera ejecución de vibebox descarga una imagen base Debian y la aprovisiona. Después de eso, las instancias por proyecto reutilizan la imagen base en caché para inicios mucho más rápidos.

Documentación

Inicio rápido

En la primera ejecución, VibeBox crea vibebox.toml en tu proyecto (si falta) y un directorio .vibebox/ para los datos de la instancia.

Configuración (vibebox.toml)

vibebox.toml reside en la raíz de tu proyecto por defecto. Puedes sobrescribirlo con vibebox -c ruta/a/vibebox.toml o la variable de entorno VIBEBOX_CONFIG_PATH, pero la ruta debe permanecer dentro del directorio del proyecto.

Configuración por defecto (se crea automáticamente cuando falta):

disk_gb solo se aplica cuando se crea el disco de la instancia por primera vez. Si lo cambias después, ejecuta vibebox reset para recrear el disco.

Montajes

• Tu proyecto se monta en lectura/escritura en ~/<nombre-del-proyecto>, y el shell arranca allí.
• Si existe un directorio .git, se enmascara con un montaje tmpfs dentro de la VM para desalentar ediciones accidentales desde el invitado.
• Los montajes adicionales provienen de box.mounts con el formato host:guest[:read-only|read-write].
• Las rutas del anfitrión soportan expansión de ~. Las rutas relativas del invitado se tratan como /root/<ruta>.
• Las rutas del invitado que usan ~ se enlazan a /home/<ssh-user> por conveniencia. Ejecuta vibebox explain para ver las asignaciones resueltas de anfitrión/invitado.

Comandos CLI

Dentro de la VM

• Usuario SSH por defecto: vibecoder
• Nombre de host: vibebox
• El aprovisionamiento de la imagen base instala: herramientas de compilación, git, curl, ripgrep, openssh-server y sudo.
• En el primer inicio de sesión, VibeBox instala mise y configura herramientas como uv, node, @openai/codex y @anthropic-ai/claude-code (mejor esfuerzo).
• Alias de shell: :help y :exit.

Estado y Caché

• El estado del proyecto reside en .vibebox/ (disco de instancia, claves SSH, logs, socket/pid del gestor). vibebox reset lo elimina.
• La caché global reside en ~/.cache/vibebox (imagen base + caché compartida del invitado). vibebox purge-cache la limpia.
• El índice de sesiones reside en ~/.vibebox/sessions y se muestra con vibebox list.

Contribuciones

Si estás interesado en contribuir a VibeBox, por favor lee nuestra guía de contribución antes de enviar un pull request.

FAQ

¿En qué se diferencia de otros sandboxes?

VibeBox está construido para sandboxes locales rápidos y repetibles con mínima ceremonia. Lo que es diferente aquí:

• La reentrada en caliente suele ser <5s en mi M3 (varía según la máquina/caché), así que puedes volver a entrar rápidamente.
• Un solo comando simple — vibebox — te lleva al sandbox desde tu proyecto.
• La configuración reside en vibebox.toml, donde puedes establecer CPU, RAM, tamaño de disco y montajes.
• Las sesiones son de primera clase: reutilizar, múltiples terminales, limpieza.

Agradecimientos especiales

vibe por lynaghk.

Y la increíble comunidad de Rust — sin el ecosistema y el toolchain como crates.io, ¡esto no sería posible!

Sígueme en X x.com/robcholz