mirror of
https://github.com/robcholz/vibebox.git
synced 2026-08-09 17:16:01 +02:00
doc: update
This commit is contained in:
robcholz
@@ -5,7 +5,7 @@
|
||||
</picture>
|
||||
</a>
|
||||
</p>
|
||||
<p align="center">Your ultrafast open source AI sandbox.</p>
|
||||
<p align="center">an ultrafast, open-source sandbox for running coding agents safely.</p>
|
||||
|
||||
<p align="center">
|
||||
<a href="https://crates.io/crates/vibebox">
|
||||
@@ -24,45 +24,77 @@
|
||||
<a href="README.zh.md">简体中文</a>
|
||||
</p>
|
||||
|
||||
**VibeBox is a per-project micro-VM sandbox for coding agents on macOS (Apple Virtualization Framework), fast to enter,
|
||||
configurable, and built around sessions.**
|
||||
**VibeBox is a per-project micro-VM sandbox for running coding agents on macOS (Apple Virtualization Framework).**
|
||||
It’s optimized for a *daily-driver* workflow: fast warm re-entry, explicit mounts, and reusable sessions.
|
||||
|
||||
- **Enter in seconds:** `vibebox` drops you into a reusable sandbox for the current repo
|
||||
- **Project-scoped:** explicit mounts + repo-contained changes
|
||||
- **Sessioned:** multi-instance + session management (reuse, multiple terminals, cleanup)
|
||||
**Who it’s for:** macOS users running coding agents who want real isolation without giving up a fast daily workflow.
|
||||
|
||||
**Quick facts:** warm re-entry is typically **<5s** on my M3 (varies by machine/cache); first run downloads and
|
||||
provisions a Debian base image (network dependent).
|
||||
|
||||
**Security model:** Linux guest VM with explicit mount allowlists from `vibebox.toml` (repo-first, everything else
|
||||
opt-in).
|
||||
|
||||
- **enter/attach in seconds:** `vibebox` drops you into a reusable sandbox for the current repo
|
||||
- **project-scoped by default:** explicit mounts + repo-contained changes (repo-first, everything else is allowlisted)
|
||||
- **sessioned:** multi-instance + session management (reuse, multiple terminals, cleanup)
|
||||
|
||||
### Quick Demo
|
||||
|
||||
```bash
|
||||
# 1) from any repo
|
||||
# from any repo
|
||||
cd my-project
|
||||
vibebox
|
||||
```
|
||||
|
||||
What you should see (roughly):
|
||||
|
||||
```text
|
||||
vibebox: starting (session: my-project)
|
||||
vibebox: attaching...
|
||||
vibecoder@vibebox:~/my-project$
|
||||
```
|
||||
|
||||
[](https://vibebox.robcholz.com)
|
||||
|
||||
---
|
||||
|
||||
### Why I built VibeBox
|
||||
|
||||
I use agents like Codex and CC a lot, but I always felt uneasy running them directly on my host machine. If I lock
|
||||
things
|
||||
down, I get interrupted by constant “are you sure?” prompts. If I loosen it up, I worry the agent might touch the
|
||||
wrong files or run something I didn’t intend.
|
||||
I use coding agents daily, and I wanted to give them a real shell without handing them my host machine.
|
||||
Lock things down and you get nonstop confirmations; loosen it up and you worry about deleting files, touching secrets,
|
||||
or wandering outside the repo.
|
||||
|
||||
I wanted something that feels as frictionless as giving an agent a real shell, but with a hard isolation boundary. So I
|
||||
built VibeBox: a per-project micro-VM sandbox that starts fast, keeps changes contained to the repo, and lets me iterate
|
||||
without babysitting permissions.
|
||||
VibeBox is the middle ground: a per-repo sandbox with a hard VM boundary, fast re-entry, and explicit mounts. It’s built
|
||||
to be “always on” for agent work without turning safety into a chore.
|
||||
|
||||
### Why a micro-VM (vs containers)?
|
||||
|
||||
Containers are great. VibeBox isn’t trying to replace Docker/devcontainers for building services.
|
||||
|
||||
I specifically wanted a VM-shaped default for agent workflows on macOS:
|
||||
|
||||
- **guest-kernel isolation boundary by default:** when I’m letting an agent run arbitrary commands, I want “safe mode”
|
||||
to
|
||||
be a Linux guest, not my host.
|
||||
- **sessions as a first-class workflow:** attach/reuse per repo, multiple terminals into the same sandbox, reliable
|
||||
cleanup to avoid orphan environments.
|
||||
- **explicit mount allowlists as the primary UX:** repo-scoped by default; anything else is an explicit decision.
|
||||
- **minimal per-repo setup:** you *can* reproduce parts of this with compose/devcontainers, but I wanted a single
|
||||
command
|
||||
that works repo-to-repo without maintaining container configs for the basic “safe shell” workflow.
|
||||
|
||||
### Comparison
|
||||
|
||||
Here’s why I didn’t just use existing options:
|
||||
|
||||
- **vibe**: super convenient, but it’s too minimal for what I need. It lacks basic configuration, and it doesn’t give me
|
||||
the multi-instance + session management my workflow wants.
|
||||
- **vibe**: super convenient and nails “zero-config, just go”. VibeBox is intentionally on a different axis: per-repo
|
||||
config + sessions + multi-instance lifecycle.
|
||||
- **QEMU**: powerful, but the configuration surface area is huge. For day-to-day sandboxing it’s not “open a repo and
|
||||
go” — it’s a project on its own.
|
||||
- **Docker / devcontainers**: great ecosystem, but for daily use it feels heavy.
|
||||
- **Docker / devcontainers / devpods**: great ecosystem. My friction wasn’t raw startup time, it was the day-to-day
|
||||
overhead of keeping per-repo agent sandboxes *safe-by-default* (mount allowlists, secrets exposure, attach/reuse,
|
||||
cleanup) without maintaining container configs per repo for the basic workflow.
|
||||
|
||||
That’s what pushed me to build **VibeBox**: I wanted a per-project sandbox that’s fast to enter (just `vibebox`),
|
||||
supports real configuration + sessions, and keeps a hard isolation boundary.
|
||||
@@ -70,13 +102,13 @@ supports real configuration + sessions, and keeps a hard isolation boundary.
|
||||
### Installation
|
||||
|
||||
```bash
|
||||
# YOLO
|
||||
# install script
|
||||
curl -fsSL https://raw.githubusercontent.com/robcholz/vibebox/main/install | bash
|
||||
|
||||
# Package managers
|
||||
# package managers
|
||||
cargo install vibebox
|
||||
|
||||
# Or manually
|
||||
# manual install
|
||||
curl -LO https://github.com/robcholz/vibebox/releases/download/latest/vibebox-macos-arm64.zip
|
||||
unzip vibebox-macos-arm64.zip
|
||||
mkdir -p ~/.local/bin
|
||||
@@ -86,7 +118,7 @@ export PATH="$HOME/.local/bin:$PATH"
|
||||
|
||||
**Requirements**
|
||||
|
||||
- macOS on Apple Silicon (Vibebox uses Apple's virtualization APIs).
|
||||
- macOS on Apple Silicon (VibeBox uses Apple's virtualization APIs).
|
||||
|
||||
**First Run**
|
||||
|
||||
@@ -102,7 +134,7 @@ cd /path/to/your/project
|
||||
vibebox
|
||||
```
|
||||
|
||||
On first run, Vibebox creates `vibebox.toml` in your project (if missing) and a `.vibebox/` directory for instance data.
|
||||
On first run, VibeBox creates `vibebox.toml` in your project (if missing) and a `.vibebox/` directory for instance data.
|
||||
|
||||
**Configuration (`vibebox.toml`)**
|
||||
|
||||
@@ -153,7 +185,7 @@ vibebox explain # show mounts and network info
|
||||
- Default SSH user: `vibecoder`
|
||||
- Hostname: `vibebox`
|
||||
- Base image provisioning installs: build tools, `git`, `curl`, `ripgrep`, `openssh-server`, and `sudo`.
|
||||
- On first login, Vibebox installs `mise` and configures tools like `uv`, `node`, `@openai/codex`, and
|
||||
- On first login, VibeBox installs `mise` and configures tools like `uv`, `node`, `@openai/codex`, and
|
||||
`@anthropic-ai/claude-code` (best-effort).
|
||||
- Shell aliases: `:help` and `:exit`.
|
||||
|
||||
@@ -168,27 +200,24 @@ vibebox explain # show mounts and network info
|
||||
If you're interested in contributing to VibeBox, please read our [contributing docs](CONTRIBUTING.md) before
|
||||
submitting a pull request.
|
||||
|
||||
### Using VibeBox
|
||||
|
||||
Feel free to use
|
||||
|
||||
### FAQ
|
||||
|
||||
#### How is this different from other Sandboxes?
|
||||
#### How is this different from other sandboxes?
|
||||
|
||||
Vibebox is built for fast, repeatable local sandboxes with minimal ceremony. What’s different here:
|
||||
VibeBox is built for fast, repeatable local sandboxes with minimal ceremony. What’s different here:
|
||||
|
||||
- Warm startup is typically under **6 seconds** on my M3, so you can jump back in quickly.
|
||||
- Warm re-entry is typically **<5s** on my M3 (varies by machine/cache), so you can jump back in quickly.
|
||||
- One simple command — `vibebox` — drops you into the sandbox from your project.
|
||||
- Configuration lives in `vibebox.toml`, where you can set CPU, RAM, disk size, and mounts.
|
||||
- Sessions are first-class: reuse, multiple terminals, cleanup.
|
||||
|
||||
### Special Thank
|
||||
### Special thanks
|
||||
|
||||
[vibe](https://github.com/lynaghk/vibe) by lynaghk.
|
||||
|
||||
And amazing Rust community, without your rich crates and fantastic toolchain like [crates.io](https://crates.io), this
|
||||
wouldn't be possible!
|
||||
And the amazing Rust community — without the ecosystem and toolchain like [crates.io](https://crates.io), this wouldn't
|
||||
be possible!
|
||||
|
||||
---
|
||||
|
||||
**Follow me on X** [X.com](https://x.com/robcholz)
|
||||
**Follow me on X** [x.com/robcholz](https://x.com/robcholz)
|
||||
|
||||
Reference in New Issue
Block a user