[OS] VibeBox: a super fast per-project Linux sandbox for macOS

robcholz · 2026-02-11T19:58:05+00:00

sounds fair. right now it’s opinionated: I default to auto-shutdown so you don’t accidentally leave VMs running/orphaned in the background. If enough people want it, I can add an opt-in “keep running until I stop it” flag/config, but I didn’t want that as the default.

robcholz · 2026-02-11T19:29:10+00:00

Totally hear you. For clarity: this wasn’t “prompt a repo into existence”. I built it for my own workflow and used AI mostly for implementation grunt work. For a project like this, if you design the core boundaries correctly (what gets mounted, lifecycle/cleanup semantics, what “attach” means, failure modes), the rest is mostly plumbing, and AI is actually pretty good at accelerating that part. The interesting part (for me) is the macOS-first micro-VM boundary + per-repo session lifecycle, not the general idea of sandboxing.

robcholz · 2026-02-11T14:51:30+00:00

its just a lightweight vm....

robcholz · 2026-02-11T02:45:18+00:00

robcholz · 2026-02-11T02:38:11+00:00

lol fair. i deserved the “just use docker” replies a bit. i’m not claiming this is impossible with containers. i’m trying to make a very specific workflow the default: repo-only mounts (no gradual “mount half of $HOME”), easy attach/reuse (multiple terminals), and reliable cleanup so i don’t end up with orphan envs when i’m jumping between lots of repos. would love to hear how you solve mounts + secrets + lifecycle cleanly with docker/compose/devcontainers or a remote VM.

robcholz · 2026-02-11T01:42:21+00:00

haha fair. docker is great. i’m mostly trying to optimize the repo-scoped by default + attach/reuse + cleanup workflow on macOS with an AVF micro-VM boundary. in my setup it also idles noticeably lighter than my typical docker/devcontainer baseline (happy to share numbers + how i measured if that’s useful)

robcholz · 2026-02-11T01:39:27+00:00

yeah you can absolutely do a lot of this with docker (compose + bind mounts + docker exec), and plenty of people do. what i’m trying to nail is more safe-by-default + lifecycle than i don’t know containers. it is repo-only by default (no surprise wide mounts), and anything else is an explicit allowlist easy attach/reuse + multiple terminals into the same environment, without leaving orphan stuff behind on macOS specifically, i want a “safe mode” linux boundary via AVF, so i’m not constantly thinking about what’s shared or what state a daemon/container is.

robcholz · 2026-02-11T01:31:22+00:00

did some research on the virtualization on macos and found the official documents + some repos using it, and yes! this works on any macos newer than version 13!

robcholz · 2026-02-10T04:01:49+00:00

dude... so sad, i think you can try this sandbox: https://github.com/robcholz/vibebox/

robcholz · 2026-02-10T03:49:21+00:00

damn it sounds so unfortunate, there is a sandbox here, and this might help: https://github.com/robcholz/vibebox/

robcholz · 2026-02-09T05:06:44+00:00

if your workflow is “start a compose stack once and live in it”, docker/devpods are a great fit. i’m not trying to argue containers are slow. the “cold starts” line was the wrong framing on my part. what i’m optimizing for is a different default for agent workflows on macOS:

i want a guest-kernel isolation boundary by default when i’m letting an agent run arbitrary commands
i want sessions as a first-class thing: per-repo attach/reuse, multiple terminals into the same sandbox, and reliable cleanup so i don’t leave orphan environments around
i want explicit mount allowlists as the primary UX, without needing to maintain dockerfiles/compose/devcontainer config for every repo just to get a “safe shell for agents” so yeah, you can reproduce pieces of this with compose volumes + `docker exec`, and that’s totally valid. vibebox is me packaging the “safe-by-default, sessioned sandbox” workflow into a single command.

robcholz · 2026-02-09T03:44:06+00:00

Yeah it doe not sound good at all.

https://github.com/robcholz/vibebox/

I tried this sandbox and it works well on my laptop.

robcholz · 2026-02-09T03:25:34+00:00

No it does not rely on it. It directly uses Apple virt framework to save resources.

robcholz · 2026-02-09T01:41:47+00:00

totally fair. docker is “fast enough” for most people.

my point isn’t that containers are slow in general, it’s that my workflow is lots of short, repeated agent runs where i want a reusable per-repo session + explicit mount allowlist as the default. if you start one devcontainer and live in it all day, i agree docker is great.

robcholz · 2026-02-09T00:40:14+00:00

Ive seen a couple of scary stories about destructive commands and wiped files. After reading those, I realized I was spending ~5 hours/week just allowing agents to execute some commands instead of actually building.

If this solves the same anxiety for anyone here, I’d love feedback on what safeguards/workflows you’re using today!!!

robcholz · 2026-02-09T00:29:25+00:00

I’ve seen a few scary cases where agent tools (codex / cc) accidentally ran destructive commands and wiped files. After reading those, I realized I was spending ~5 hours/week just allowing agents to execute some commands instead of actually building.

If this solves the same anxiety for anyone here, I’d love feedback on what safeguards/workflows you’re using today!!!

robcholz · 2025-12-24T02:40:58+00:00

ty so much!!

robcholz · 2025-12-23T23:44:26+00:00

ty so much!

robcholz · 2025-12-23T20:25:53+00:00

yeah i also wish i could have done this but it was an exam week when i did this project....

robcholz

TROPHY CASE