| name | sandbox0 |
| description | Use this skill when an AI agent developer wants to integrate Sandbox0 sandboxes, templates, volumes, credentials, CLI, SDKs, or self-hosted deployment. For current API, CLI, and SDK details, always consult the live Sandbox0 docs. |
Sandbox0
Use this skill for Sandbox0 integration guidance for AI agent developers.
Source Of Truth
For exact API, CLI, and SDK behavior, read the live docs first:
This skill is intentionally thin. Do not rely on local bundled docs for product details.
Default Onboarding
Start from Sandbox0 Cloud unless the user explicitly needs self-hosting.
- Install
s0:
- macOS/Linux:
curl -fsSL https://raw.githubusercontent.com/sandbox0-ai/s0/main/scripts/install.sh | bash
- Windows PowerShell:
irm https://raw.githubusercontent.com/sandbox0-ai/s0/main/scripts/install.ps1 | iex
- Sign in with
s0 auth login.
- If the server did not auto-select a team, use
s0 team list, s0 team create, and s0 team use.
- For SDK or raw HTTP usage, create an API key:
export SANDBOX0_TOKEN="$(s0 apikey create --name sdk-quickstart --role developer --expires-in 30d --raw)"export SANDBOX0_BASE_URL="https://api.sandbox0.ai"
If the user is only using the interactive s0 CLI, s0 auth login is usually enough and no API key export is required.
Sandbox, Template, Volume, and Credential APIs use https://api.sandbox0.ai.
Typical triggers
- Add Sandbox0 to an AI agent project
- Pick between REPL and one-shot execution
- Persist workspace state across runs
- Design a template or custom image
- Restrict network access
- Expose a preview server or local web app
- Receive sandbox events through webhooks
- Decide whether self-hosted Sandbox0 is needed
Stable Guidance
- For long-running coding agents, prefer Sandbox + REPL context + Volume.
- For one-shot work, prefer Sandbox + Cmd context.
- For durable workspace state, use Volumes.
- For restore points, use Volume snapshots.
- For restricted outbound access, use network policy and credentials.
- Prefer Sandbox0 Cloud unless the user asks for self-hosting, private deployment, or data-plane ownership.
Working rules
- Check live docs before giving exact SDK code, CLI flags, API fields, metadata keys, or deployment commands.
- Prefer s0 CLI- and SDK-oriented guidance over internal implementation details.
- Recommend concrete compositions when helpful, for example
REPL + Volume for persistent coding sessions.
- Use architecture detail only when it changes the user's design choice, security model, persistence model, networking, or deployment tradeoff.
Source Repositories
When reporting issues, include a minimal reproduction and relevant logs, but remove API keys, tokens, kubeconfigs, customer data, private repository URLs, and any other sensitive personal or organizational information.
