| name | devbox |
| description | Boot and operate isolated per-branch dev containers with a headed display (noVNC), Pi/Claude Code/Codex agent, Chromium for OAuth, and GitHub-token forwarding. Use this skill whenever the user wants to work on a branch in an isolated container, run or test GUI/Electron apps headlessly via a browser-viewable display, do OAuth flows inside a container, spin up a clean per-branch environment, or use `npx @gannonh/devbox` / `devbox`. Also trigger when the user mentions devbox, dev containers per worktree, noVNC dev boxes, or wants isolated environments that don't pollute their host. Even if they don't say "devbox" explicitly, reach for it when they describe wanting a fresh, throwaway, or isolated environment for a branch or feature. |
devbox
devbox gives every git branch its own isolated container with a headed display (viewable in a browser via noVNC), a coding agent, Chromium for OAuth flows, and GitHub-token forwarding. One command boots a box; teardown is one command too.
When to use devbox
Reach for devbox when the user would benefit from a clean, isolated, per-branch environment:
- They want to work on a branch without messing up their host install or other branches.
- They need to run or test a GUI/Electron app and see it (noVNC renders the display in a browser).
- They're doing an OAuth flow that needs a browser callback, and want it contained.
- They want a fresh
node_modules/build state that doesn't conflict with the main checkout.
- They explicitly say "devbox", "isolated container", "per-branch environment", or use
npx @gannonh/devbox / devbox.
devbox is not the right tool for running the project's unit tests on the host, editing files outside a worktree, or one-off shell commands. It boots a full container, so prefer it when isolation or a display actually helps.
Prerequisites (host)
These live on the host, not in the box. Check them before booting a box for the first time in a repo:
