2 <a href="https://vibebox.robcholz.com">
4 <img src="docs/banner.png" alt="VibeBox logo">
8<p align="center">an ultrafast, open-source sandbox for running coding agents safely.</p>
11 <a href="https://crates.io/crates/vibebox">
12 <img alt="Crates.io" src="https://img.shields.io/crates/v/vibebox.svg">
14 <a href="https://github.com/robcholz/vibebox/blob/main/LICENSE">
15 <img alt="MIT licensed" src="https://img.shields.io/badge/license-MIT-blue.svg">
17 <a href="https://github.com/robcholz/vibebox/actions?query=workflow%3ACI+branch%3Amain">
18 <img alt="Build Status" src="https://github.com/robcholz/vibebox/workflows/CI/badge.svg">
23 <a href="README.md">English</a> |
24 <a href="README.zh.md">简体中文</a>
27**VibeBox is a per-project micro-VM sandbox for running coding agents on macOS (Apple Virtualization Framework).**
28It’s optimized for a *daily-driver* workflow: fast warm re-entry, explicit mounts, and reusable sessions.
30**Who it’s for:** macOS users running coding agents who want real isolation without giving up a fast daily workflow.
32**Quick facts:** warm re-entry is typically **<5s** on my M3 (varies by machine/cache); first run downloads and
33provisions a Debian base image (network dependent).
35**Security model:** Linux guest VM with explicit mount allowlists from `vibebox.toml` (repo-first, everything else
38- **enter/attach in seconds:** `vibebox` drops you into a reusable sandbox for the current repo
39- **project-scoped by default:** explicit mounts + repo-contained changes (repo-first, everything else is allowlisted)
40- **sessioned:** multi-instance + session management (reuse, multiple terminals, cleanup)
50What you should see (roughly):
53vibebox: starting (session: my-project)
55vibecoder@vibebox:~/my-project$
58[](https://vibebox.robcholz.com)
62### Why I built VibeBox
64I use coding agents daily, and I wanted to give them a real shell without handing them my host machine.
65Lock things down and you get nonstop confirmations; loosen it up and you worry about deleting files, touching secrets,
66or wandering outside the repo.
68VibeBox is the middle ground: a per-repo sandbox with a hard VM boundary, fast re-entry, and explicit mounts. It’s built
69to be “always on” for agent work without turning safety into a chore.
71### Why a micro-VM (vs containers)?
73Containers are great. VibeBox isn’t trying to replace Docker/devcontainers for building services.
75I specifically wanted a VM-shaped default for agent workflows on macOS:
77- **guest-kernel isolation boundary by default:** when I’m letting an agent run arbitrary commands, I want “safe mode”
79 be a Linux guest, not my host.
80- **sessions as a first-class workflow:** attach/reuse per repo, multiple terminals into the same sandbox, reliable
81 cleanup to avoid orphan environments.
82- **explicit mount allowlists as the primary UX:** repo-scoped by default; anything else is an explicit decision.
83- **minimal per-repo setup:** you *can* reproduce parts of this with compose/devcontainers, but I wanted a single
85 that works repo-to-repo without maintaining container configs for the basic “safe shell” workflow.
89Here’s why I didn’t just use existing options:
91- **vibe**: super convenient and nails “zero-config, just go”. VibeBox is intentionally on a different axis: per-repo
92 config + sessions + multi-instance lifecycle.
93- **QEMU**: powerful, but the configuration surface area is huge. For day-to-day sandboxing it’s not “open a repo and
94 go” — it’s a project on its own.
95- **Docker / devcontainers / devpods**: great ecosystem. My friction wasn’t raw startup time, it was the day-to-day
96 overhead of keeping per-repo agent sandboxes *safe-by-default* (mount allowlists, secrets exposure, attach/reuse,
97 cleanup) without maintaining container configs per repo for the basic workflow.
99That’s what pushed me to build **VibeBox**: I wanted a per-project sandbox that’s fast to enter (just `vibebox`),
100supports real configuration + sessions, and keeps a hard isolation boundary.
106curl -fsSL https://raw.githubusercontent.com/robcholz/vibebox/main/install | bash
112curl -LO https://github.com/robcholz/vibebox/releases/download/latest/vibebox-macos-arm64.zip
113unzip vibebox-macos-arm64.zip
115mv vibebox ~/.local/bin
116export PATH="$HOME/.local/bin:$PATH"
121- macOS on Apple Silicon (VibeBox uses Apple's virtualization APIs).
125The first `vibebox` run downloads a Debian base image and provisions it. After that, per-project instances reuse the
126cached base image for much faster startups.
133cd /path/to/your/project
137On first run, VibeBox creates `vibebox.toml` in your project (if missing) and a `.vibebox/` directory for instance data.
139**Configuration (`vibebox.toml`)**
141`vibebox.toml` lives in your project root by default. You can override it with `vibebox -c path/to/vibebox.toml` or the
142`VIBEBOX_CONFIG_PATH` env var, but the path must stay inside the project directory.
144Default config (auto-created when missing):
152 "~/.codex:~/.codex:read-write",
153 "~/.claude:~/.claude:read-write",
157auto_shutdown_ms = 20000
160`disk_gb` is only applied when the instance disk is first created. If you change it later, run `vibebox reset` to
165- Your project is mounted read-write at `~/<project-name>`, and the shell starts there.
166- If a `.git` directory exists, it is masked with a tmpfs mount inside the VM to discourage accidental edits from the
168- Extra mounts come from `box.mounts` with the format `host:guest[:read-only|read-write]`.
169- Host paths support `~` expansion. Relative guest paths are treated as `/root/<path>`.
170- Guest paths that use `~` are linked into `/home/<ssh-user>` for convenience. Run `vibebox explain` to see the resolved
176vibebox # start or attach to the current project VM
177vibebox list # list known project sessions
178vibebox reset # delete .vibebox for this project and recreate on next run
179vibebox purge-cache # delete the global cache (~/.cache/vibebox)
180vibebox explain # show mounts and network info
185- Default SSH user: `vibecoder`
187- Base image provisioning installs: build tools, `git`, `curl`, `ripgrep`, `openssh-server`, and `sudo`.
188- On first login, VibeBox installs `mise` and configures tools like `uv`, `node`, `@openai/codex`, and
189 `@anthropic-ai/claude-code` (best-effort).
190- Shell aliases: `:help` and `:exit`.
194- Project state lives in `.vibebox/` (instance disk, SSH keys, logs, manager socket/pid). `vibebox reset` removes it.
195- Global cache lives in `~/.cache/vibebox` (base image + shared guest cache). `vibebox purge-cache` clears it.
196- Session index lives in `~/.vibebox/sessions` and is shown by `vibebox list`.
200If you're interested in contributing to VibeBox, please read our [contributing docs](CONTRIBUTING.md) before
201submitting a pull request.
205#### How is this different from other sandboxes?
207VibeBox is built for fast, repeatable local sandboxes with minimal ceremony. What’s different here:
209- Warm re-entry is typically **<5s** on my M3 (varies by machine/cache), so you can jump back in quickly.
210- One simple command — `vibebox` — drops you into the sandbox from your project.
211- Configuration lives in `vibebox.toml`, where you can set CPU, RAM, disk size, and mounts.
212- Sessions are first-class: reuse, multiple terminals, cleanup.
216[vibe](https://github.com/lynaghk/vibe) by lynaghk.
218And the amazing Rust community — without the ecosystem and toolchain like [crates.io](https://crates.io), this wouldn't
223**Follow me on X** [x.com/robcholz](https://x.com/robcholz)
keysesc to close
- j k
- move down, up
- enter
- open
- esc
- back, or up a level
- 1 2 3 4
- readme, files, commits, refs
- /
- filter
- y
- copy the clone command
- c
- compare the chosen commit with another (or shift-click both)
- ?
- show or hide this list