David Karlsson
3de2f99327
## Description Add cloud Sandboxes documentation for sbx v0.45.0, covering credentials, network policy, lifecycle, environment files, and transfers between local and cloud sandboxes. Document named sandbox reuse and resume, resource sizes and platform selection, custom secrets, move behavior, and local UDP guidance. Link to the canonical Docker Agentic Platform signup, billing, and Console MCP instructions. Keep CLI sign-in, access checks, and cloud credential setup in the Sandboxes guides. This PR also vendors the CLI reference including `sbx move`, and aligns timeout and move guidance with it. Kits v3 and API/SDK documentation are handled separately. Validation: scoped Markdown and Vale checks and a full Hugo build passed. Cloud and Agentic Platform guides passed rendered internal link and anchor checks, including the canonical signup page's discovery. The earlier CLI import verified all 119 vendored files against upstream byte-for-byte and checked 1,083 rendered CLI-reference links and anchors. Behavior was checked against source; live cloud workflows and checkout were not exercised. @netlify /ai/sandboxes/cloud/ Generated by Codex
5.0 KiB
title, linkTitle, description, keywords, weight, aliases
| title | linkTitle | description | keywords | weight | aliases | |
|---|---|---|---|---|---|---|
| Run your coding agent in a sandbox | Sandbox a coding agent | Move your existing AI coding agent workflow into a disposable Docker Sandbox. | Docker, get started, AI agents, coding agents, Docker Sandboxes, sbx, sandbox, YOLO mode | 2 |
|
Coding agents can work faster in full-autonomy modes that let them run commands, install tools, and use Docker without stopping for approval. Giving an agent that access directly on your machine also gives mistakes a wider reach.
Docker Sandboxes change where the agent runs, not how you work with it. The agent gets a private environment with its own operating system and Docker daemon. Your project remains available on your host, while tools the agent installs and system changes it makes stay inside an environment you can discard.
In this tutorial, you'll move an existing coding-agent workflow into a local sandbox. For a cloud workflow, see Get started with cloud sandboxes.
Before you start
- Have a project directory for the agent to work with
- Have access to a supported coding agent
You don't need Docker Desktop or Docker Engine on your host.
Install and sign in
Install Docker Sandboxes for your operating system, then sign in to Docker:
$ sbx login
Bring your agent setup
This step is optional. Skip it if you want to start with a clean agent setup.
If you use agent skills on your host, preview and import them:
$ sbx skills import --dry-run
$ sbx skills import
Imported skills become available to supported agents across your sandboxes. This feature is experimental. See Share agent skills for supported agents and security considerations.
Choose how to authenticate
Your agent needs access to a model provider. Subscription sign-in uses OAuth, while API keys are stored on your host and supplied to the agent through the sandbox proxy. Choose your agent and authentication method for the preparation steps:
{{< sandbox-auth >}}
If you already exported a supported API key in your shell, you can import it instead of setting it separately:
$ sbx secret import --dry-run
$ sbx secret import
The dry run shows which exported keys sbx found. The import command prompts
you to confirm each key before storing it. If the dry run finds nothing, use
the sbx secret set command from the picker. See
Credentials for other
secret sources and supported coding agents
for agent-specific authentication.
Run your agent
Open your project and start your preferred agent. This example uses Codex:
$ cd ~/my-project
$ sbx run --name my-project codex
Replace codex with another supported agent identifier, such as claude,
copilot, cursor, or gemini.
The first time you run a sandbox, sbx asks you to choose a default network
policy. This policy controls which external services your sandboxes can reach.
Select Balanced to permit common development services and block other
destinations by default. You can change these rules later with
sbx policy.
The built-in integrations start coding agents in their full-autonomy mode. For example, Codex bypasses approvals, Claude Code skips permission prompts, and Cursor, Copilot, and Gemini use YOLO mode. You don't need to add those flags.
Give the agent the same task you would give it on your host. Source changes appear in your working tree, so you can inspect them with your usual tools:
$ git diff
Your project directory is the exception to the sandbox boundary. It is shared read-write, so the agent can modify or delete its files and you can see those changes immediately. Keep your work under version control. Tools the agent installs and changes to the sandbox's operating system stay inside the sandbox.
Return or start over
Exit the agent when you're finished. Reconnect to the same environment later:
$ sbx run --name my-project
When you want a clean environment, remove the sandbox:
$ sbx rm my-project
Removing the sandbox deletes the environment and everything installed inside it. It doesn't delete your project directory.
What changed
You kept your project, agent, skills, credentials, and prompting workflow. The
only essential change was launching the agent with sbx run. That moved its
full-autonomy execution into an environment you control and can throw away.
What's next
Continue with the Docker Sandboxes manuals:
- Manage your sandboxes with day-to-day commands
- Configure your coding agent for its authentication and settings
- Review the security defaults for workspace, network, and credential access