SBX(1)SBX(1)

NAME

sbx - sandboxed docker dev environments that grew into an ai agent fleet

SYNOPSIS

sbx init
sbx shell
sbx run

DESCRIPTION

sbx started as a single Rust binary for sandboxed Docker dev environments. Pick a flavor (npm, pnpm, bun, rust, java, claude, codex and more), run sbx init, then sbx shell or sbx run. The container gets the repo, mounted at its host path, and nothing else. There's no host home, SSH agent, docker socket or host network unless you opt in, so a compromised dependency or AI agent can't reach SSH keys, cloud credentials or other projects.

Outbound traffic can go through an allow-listed proxy, exposure through Cloudflare or Tailscale, and TLS ends in a sidecar so secrets stay per-project. Claude Code, Codex, opencode and Copilot launch with isolated profiles and rotate logins on their own, and a dashboard watches every tmux pane and resumes rate-limited sessions.

The biggest part now is the agent fleet. Each task in a git-backed queue gets its own worktree and sandboxed agent, and a deterministic scheduler decides what runs. Finished tasks are rebased, verified, squashed, signed and fast-forwarded onto master through a staging branch, authored as me. No LLM touches scheduling or merging, and nothing pushes.

The queue owner can put workers and compiles on peer machines, verify batches as bisected runs across them, and spill over to Claude cloud sessions when local allowance runs out. A TanStack Start hub shows it all in the browser and as a phone PWA, with live terminals, a task graph, deploys, previews, and usage and cost tracking. It runs highly available on my k3s cluster. It's still in development, so the repo is private for now.

DESIGN

Default-deny sandboxes
Each project's config.toml is merged from a private copy, the git common dir and the working tree, and declares exactly what the container gets: mounts, caches, ports, services, and opt-in sockets for SSH, Docker, PM2, KVM or a GUI. Anything not declared isn't there. Weaker than a VM, but a sane default for running npm install.
A fleet with no LLM in the loop
The queue in .sbx/queue is the record. Agents plan and write code, but admission, scheduling, verification and landing are plain deterministic code. Finished tasks integrate onto a staging branch, and master only advances by merge --ff-only from it, so the fleet stops at my local master and never pushes.
One queue, many machines
Only the queue owner plans, leases and integrates. It can place a worker on a peer over the hub channel. The peer fetches the exact commit into private state, runs the task in its own worktree, and sends the branch back. Compiles can leave the node the same way, and integration verifies run as bisected prefix batches on several peers at once.
The hub
A TanStack Start app with a separate realtime process. Browsers connect over Socket.IO behind better-auth RBAC, and node agents dial out to a token-authenticated WebSocket. Two web replicas share one realtime leader, elected through a Postgres lease and published to Kubernetes as an EndpointSlice.

FEATURES

  • Per-flavor sandbox images (npm, pnpm, bun, rust, java, claude, codex, ...)
  • Repo bind-mounted at its host path; no host home, SSH agent, docker socket, or host network by default
  • Shadow risky host tools like npm, bun and cargo through one-shot sandboxes
  • Built-in services (Postgres, Redis, Mongo, MySQL, Mailpit), host-proxy allowlist, Cloudflare and Tailscale exposure, TLS sidecar
  • Agent launchers for Claude Code, Codex, opencode and Copilot with isolated profiles and login rotation on weekly limits
  • Dashboard that auto-continues rate-limited sessions and notifies via Discord, ntfy, desktop and web push
  • Git-backed task queue where each task gets its own worktree and sandboxed agent
  • Planner, design review, approvals, task ordering, and scope-contention handling
  • Worker pool across machines, remote build offload, and overflow to Claude cloud sessions
  • Web hub (PWA) with live terminals, task graph, deploys, previews, and usage and cost tracking
  • Headless Playwright browser MCP server baked into agent images

CHALLENGES

  • Isolating every project and agent so dependencies, build scripts and AI tools can't read host secrets or other repos
  • Keeping the scheduler and merge path deterministic, with no LLM deciding what runs or what lands
  • Landing parallel agent work through a staging branch with fast-forward-only merges, never rewriting my checkout or making a merge commit
  • Placing workers and compiles on peer nodes by load, memory, logins and images, sending only the commit and requirements a peer needs
  • Bisecting batch verifies across several peers at once so one bad task doesn't hold back the rest of a batch
  • Running the hub's realtime process highly available with a Postgres-elected lease on Kubernetes

STACK

frontend
React 19, TanStack Start, xterm.js, Tailwind CSS, ECharts
backend
Rust, clap, crossterm, better-auth, Socket.IO + raw WebSockets
database
PostgreSQL, Redis, SQLite, Drizzle ORM
tools
Docker, tmux, Kubernetes (k3s), Caddy, Cloudflare Tunnel, Tailscale, Playwright

STATUS

In development. The repository stays private until it's ready. Role: author.

SEE ALSO

2026SBX(1)
MANSBX(1)