fork creates a new machine that is an exact copy of an existing one β same filesystem, same installed packages, same data. The new machine gets its own name, HTTPS domain, and SSH port.
Usage
--json:
Use cases
Rollback
Fork before a risky change:Experimentation
Try things without affecting your working machine:Scaling
Need another instance of the same app:Forking a shared org machine
If you fork a machine thatβs shared with your organization, the fork is private to you by default β the org keeps paying, but only you can reach the copy, and your agent logins (Claude Code, Codex, OpenCode) work in it again right away. Itβs the clean way to take a shared golden machine and do focused, authenticated work on a copy without touching the shared original.Golden images
A βgolden imageβ is a long-running VM that has your app fully installed, configured, and running. You build it once β clone the repo, install dependencies, run setup scripts, start the services β then leave it running and fork from it whenever you need a warm copy. Every fork inherits the full state β code, dependencies, running services, data β and boots in ~160ms. No rebuild, no reinstall, no waiting fornpm install or container layers to pull.
Common patterns:
- Per-PR previews. Fork on every pull request, apply the branchβs diff inside the fork, share the
*.boxd.shURL with reviewers. Destroy on merge. - Per-issue agent runs. Fork the golden, hand it to Claude Code via
boxd machine exec, let the agent fix the bug inside the fork. The PR closes, the fork goes away. - Sandbox copies. Hand a fresh fork to anyone who wants to poke at the app without touching the source.
- Reproducing bugs. Fork production state, reproduce the issue safely, throw the fork away.
/boxd-setup-golden and /boxd-setup-fix skills wire this whole loop up for you. See Skills.
Claude Code only for now β reach out for Codex, OpenCode, or any other agent.