seven 🥤

seven up is vagrant up but made of sprite for safe agentic development

seven is a modern, developer-friendly replacement for the classic vagrant-based workflow, specifically engineered for the era of AI coding assistants. It runs your repo inside Fly.io Sprites: persistent, hardware‑isolated Linux microVMs you can spin up on demand. Sprites start in about a second or two, keep their filesystem between runs, and go idle when unused — so you get VM‑grade isolation without VM overhead.

Design Goals

• Make seamless and fast isolation the default for high‑autonomy agentic development.
• Provide a familiar and memorable command: seven up mirrors the old‑school vagrant up workflow, but is "made of sprite".
• Run a full OS so the agent can "close the loop" (run the dev stack, containers, and a browser).
• Enable a safe path to high‑permission workflows without forcing heavy local VM overhead.

Rationale

High‑autonomy agentic coding works best when the assistant can "close the loop": i.e. read and write files, run tests, install dependencies, make HTTP calls, control a browser. If you keep it on a tight leash with constant approvals, throughput collapses, and you inevitably develop a pavlovian response to always accept anyway. So the real question is not whether to grant high permissions, but how to make that safe.

Simon Willison’s “lethal trifecta” captures the main risk: untrusted input plus access to private data plus the ability to communicate externally. That combination makes prompt injection genuinely dangerous. While isolation doesn’t fully solve prompt injection, it shrinks the blast radius to local secrets, and makes recovery cheaper.

Besides adversarial scenarios, agents still make serious mistakes. These include mis‑typed rm -fr (aka "delete France"), aggressive global installs, lost git commits. With proper disk isolation, and not just git worktree shenanigans, these mistakes become merely annoying rather than devastating, and are much easier to recover from thanks to disk snapshots.

Containers aren't a realistic option as the agent needs to run the, typically-containerized, dev stack as well as a browser and Docker‑in‑Docker (DinD) remains a nightmare. Returning to local VMs (e.g. via Vagrant) is the obvious answer, but nowadays local virtualization adds too much friction (especially on ARM CPUs). There are various other approaches (e.g. firejail) with their own tradeoffs. In my (admitedly short) experience, sprites give you the best of all worlds — hardware‑isolated microVMs with fast startup, persistent disks, and checkpoint/restore — so you can keep a Vagrant‑style workflow without the VM overhead.

Finally, rich Cloud Development Enrivonments (CDEs) have historically been a mixed bag. While making it easier to run full development stacks without worrying about local resource constraints, they could be brittle, costly, and hard to integrate with the local toolchain. However, they provide a clear edge with agentic assistants: they run much closer to inference APIs, making development significantly snappier. And sprites can expose ports locally in cases where a PR needs manual finishing touches.

Adoption recipe

If you’re moving from "chat‑only" to fully autonomous coding, the practical path looks something like:

1. Move execution off your laptop. seven up and run the agent inside the Sprite.
2. Engineer the harness. Init AGENTS.md, add relevant skills, and require the agent to write and run tests.
3. Give real permissions. Let it edit files, run commands, install deps, and control the browser — inside the sandbox.
4. Use checkpoints + git as your safety net. Snapshot after pushes, and rollback fast when a run goes sideways.
5. Promote proven workflows. When a task pattern works, turn it into a repeatable skill or tweak AGENTS.md.

...and don't hesitate to code locally in parallel, albeit with reduced permissions.

Get Started

Install

curl -fsSL https://raw.githubusercontent.com/1to10partners/seven/main/scripts/install.sh | sh

Run

cd /path/to/your/repo
seven up

On first run, seven up will prompt you to run sprite login, then create the sprite, and finally clone your repo and handle basic git setup. If host codex is logged in using ChatGPT, seven init also copies ~/.codex/auth.json into the sprite so Codex is authenticated there. After clone, seven init configures one-shot console bootstrap for Bash, Zsh, and fish so the first sprite console opens in the cloned repo and suggests the selected assistant. Use seven up --assistant codex or seven up --assistant claude when both credentials exist and you want a deterministic choice. On each seven up, the host sprite CLI is checked for updates and auto-upgraded when a newer version is available. Subsequent runs skip init and are therefore instant.

Once inside the sprite, cd into your folder and start your favorite assistant. The following come pre-installed: claude, codex, cursor-agent, and gemini-cli.

Running multiple sprites

Each sprite is a fully isolated microVM, so running one assistant session per sprite is a clean alternative to git worktrees. seven up opens the main sprite; siblings are numbered:

seven up          # main sprite (#1)
seven up --new    # create the next sibling (#2, #3, …) and select it
seven up 2        # reopen sibling #2
seven list        # list this repo's sprite family and which one is selected (alias: ls)

Siblings are numbered consistently: the main sprite is #1, and seven up --new / seven up N / seven list all agree (the first sibling is <repo>-02). The repo is always cloned into a directory named after the project (e.g. ~/soclimmo), regardless of which sibling sprite you're in.

Fresh Sprites clone the remote repository's default branch. The host checkout identifies the repository but does not select its branch or commit, so a stale or dirty laptop checkout does not affect normal provisioning. To reproduce a pushed host branch before merge, opt in with seven up --new --from-host; that mode refuses dirty/detached checkouts and verifies the cloned HEAD is the exact host commit.

To avoid confusion when switching between consoles, each sprite gets a color-coded shell prompt (bash, zsh, and fish) plus a one-line banner naming it on entry. The color is derived from the sprite name, so a given sprite always shows the same color and siblings stay visually distinct. Each sprite also defines c as claude --dangerously-skip-permissions and c2 as codex --dangerously-bypass-approvals-and-sandbox — sprites are disposable sandboxes, so running assistants with full permissions (no per-tool prompts, no folder-trust dialog) is the convenient default.

Project tooling (per-repo, no hardcoded deps)

A repo can declare the CLIs/MCP servers its agent needs, and seven reconciles them after cloning and on every seven up — so a fresh sprite is "born" with the project's tools and an existing sprite repairs drift, with no project-specific dependencies hardcoded in seven. Opt in by committing a manifest at scripts/sprite-tooling.manifest, one tool per line. Seven supports only typed npm, pip, pip-module, archive, and gstack rows; it never executes a repository installer script.

# kind   name     pinned-spec                         verify-command
gstack  gstack   <full-40-character-commit-sha>      -
npm     vercel   vercel@54.12.2                      vercel --version
pip     ruff     ruff==0.15.18                       ruff --version
pip-module pynacl pynacl==1.6.2                      nacl 1.6.2
archive flyctl   <version>|<https-url>|<sha-x86>|<sha-arm>|flyctl|fly  flyctl version
archive shellcheck <version>|<https-url>|<sha-x86>|<sha-arm>|release-dir/shellcheck|- shellcheck --version

Install is idempotent, exact-version verified, and fail-closed: every declared row is required, so a failed reconciliation blocks the console instead of presenting a partially provisioned Sprite. Archive rows require per-architecture SHA-256 checksums and may select a safe nested member. URL templates use {arch} (x86_64/arm64) or {gnuarch} (x86_64/aarch64). A gstack row requires an immutable commit; Seven fetches it from the official origin into a fresh staging repository, atomically replaces the old checkout, and registers it for every supported assistant found in the Sprite. Later runs verify the pin, generated browser, and Codex links and skip setup when all are healthy. Repos without a manifest are unaffected. (Secrets are not handled here — tooling install only; credentials are a separate, project-owned concern.)

Assistant authentication

Host assistant credentials are copied into the sprite once, at creation, mirroring how gh auth is bootstrapped. Subsequent seven ups do not re-sync — re-running config + auth uploads for both assistants on every reconnect added noticeable latency without changing the result for a working sprite.

What's synced on the initial seven up:

• Claude Code: seven syncs the real OAuth credential store, not just ~/.claude.json. On Linux that's ~/.claude/.credentials.json; on macOS the tokens live in the login Keychain (service claude-code / Claude Code-credentials), which seven extracts and writes into the sprite. (The Keychain read may show a one-time access prompt.) ~/.claude/settings.json and ~/.claude.json are deep-merged so sprite-only keys are preserved.
• Codex: ~/.codex/auth.json and ~/.codex/config.toml are copied in.

Seven copies both assistants' available credentials regardless of which one is selected. Without an explicit --assistant, it preserves the existing auto-detection behavior; pass --assistant codex or --assistant claude to choose the console hint deterministically.

If a host token rotates and the sprite copy goes stale, run claude (or codex login) inside the sprite to re-auth — the same recovery path used for gh. Note that the host and a sprite share one refresh token, so a refresh on one side can occasionally invalidate the other ("token has already been used"); the fix is the same in-sprite re-login.

Uninstall

Remove the installed binary (defaults to ~/.local/bin):

rm -f "$(command -v seven)"

Contributing

Commands (dev workflow)

make build
./build/seven init
./build/seven up --no-tui
./build/seven status
./build/seven destroy

Integration tests (interactive)

Integration tests require an interactive Sprite login and will create/destroy a temporary sprite.

sprite login
SEVEN_INTEGRATION=1 go test -v ./cmd/seven

Releases

We ship binaries via GitHub Releases using GoReleaser. Tag a release to trigger the workflow:

git tag v0.1.0
git push origin v0.1.0

To test the release process locally without publishing (requires goreleaser):

goreleaser check
goreleaser release --snapshot --clean

Install gstack

gstack is a multi-host skill toolkit that lives outside the repo, so each fresh sprite needs its own copy. Repositories can declare it with a gstack row in scripts/sprite-tooling.manifest; for an undeclared repository, pass --gstack:

seven up --gstack

The Sprite image must already provide Bun; Seven never bootstraps it with a remote shell script. Seven fetches and verifies an immutable gstack commit, cleans ignored build/dependency artifacts, installs its frozen lockfile, then runs ./setup --host auto --no-team. Disabling team mode is intentional: its auto-updater would defeat the manifest pin. The same checkout registers skills for Claude Code, Codex, and any other supported host found in the Sprite. Re-running seven up takes a metadata-only fast path when the pinned checkout, generated browser, Playwright completion markers, and Codex skill links are healthy; it downloads and repairs only when that probe finds drift. This fast path trusts the persistent Sprite home, which already runs full-permission agents; use a new Sprite if that local state may be compromised.

Sprite images newer than Playwright's recognized Ubuntu matrix use Playwright's supported Ubuntu 24.04 compatibility build during setup. The override is scoped to that setup process and leaves recognized operating systems untouched.

Features

• Core CLI: seven init, seven up, seven destroy, seven status, seven list.
• gstack: optional --gstack install of the gstack skill toolkit into the sprite.
• Multiple sprites: seven up --new / seven up N to run one assistant session per isolated sprite, with a color-coded prompt per sprite.
• Bootstrap: resolve sprite name, create/reuse sprite, clone repo when possible, setup git.
• TUI: minimal Bubbletea UX.
• Packaging: GitHub Releases + curl installer (primary). No package managers yet.

Roadmap

1) IDE connection (VS Code and others)

Goal: Handle cases where you want to manually review code or edit files directly inside the sprite.

Planned approach:

• In-sprite editor: default to terminal editors (vim/nano) inside the sprite for quick edits.
• Full IDE in the sprite: add a seven ide flow that starts a browser‑based IDE (e.g. code‑server/openvscode‑server) inside the sprite and forwards a port to the local machine or opens in the browser.

2) Feedback loop + port forwarding

Goal: run the app inside the sprite and access it locally as if it were running on your machine, to make debugging easier.

Planned approach:

• Assistant detection: on the host, detect which assistant to use (priority order: Claude, Codex, Cursor, Gemini) based on env vars being set.
• Guided init: after cloning, write a prompt for the assistant to review the codebase and attempt to start the local dev stack inside the sprite. The prompt should ask it to identify which endpoints/ports need to be exposed.
• Forwarding: use sprite proxy to forward local ports to the sprite, based on the assistant’s findings (or a user override).
• Command surface: add seven dev to start the app in the sprite and wire up ports in one step, including any required forwarding.

3) Browser skill for agents

Goal: ensure the agent can close the loop for webapps by testing in a real browser context.

Planned approach:

• Optional install: during seven init, detect if the repo is likely a webapp and offer to install a browser skill for the selected assistant.
• Assistant‑aware: pick the right browser skill per agent (Claude/Codex/Cursor/Gemini) and configure it in the sprite.
• Safe defaults: keep it opt‑in unless a webapp is detected, and document how to enable/disable later.

References

• Fly.io Sprite docs: https://docs.sprites.dev/
• Fly.io Sprite announcement: https://fly.io/blog/code-and-let-live/
• Fly.io Sprite technical explainer: https://fly.io/blog/design-and-implementation/
• The “lethal trifecta” (Simon Willison): https://simonwillison.net/2025/Aug/9/bay-area-ai/
• My AI adoption journey (Mitchell Hashimoto): https://mitchellh.com/writing/my-ai-adoption-journey
• Running Claude Code dangerously safely (Emil Burzo): https://blog.emilburzo.com/2026/01/running-claude-code-dangerously-safely/
• Ask HN: How are you sandboxing coding agents? https://news.ycombinator.com/item?id=46400129
• HN: Running Claude Code dangerously safely: https://news.ycombinator.com/item?id=46690907
• Run Your Agent in Firejail and Stay Safe: https://softwareengineeringstandard.com/2025/12/15/ai-agents-firejail-sandbox/