Docker Sandboxes: Declarative sbxenv.yaml Environments

Overview

sbxenv.yaml (schemaVersion "1", EXPERIMENTAL) declaratively describes one sandbox environment, agent, mixin kits, workspace mounts, environment variables, secrets/registries/bindings to provision, MCP servers, ports, and host-side lifecycle commands, so sbx env create|run|plan|exec|rm can stand it up and tear it down reproducibly instead of a long flag invocation. This skill owns that file format end to end. It delegates the sandbox lifecycle semantics it wraps, the credential/network model it provisions into, and the kit schema its kits: entries reference, to their own skills.

When to use this skill

Activate this skill when:

• The user wants a checked-in, reproducible definition of a sandbox environment instead of a long sbx create/sbx run command line.
• The user wants host-side setup/teardown commands (cloning a repo, seeding fixtures, archiving state) tied to a sandbox's create/attach/remove lifecycle.
• The user wants to parameterize a shared environment file with named arguments (args: + --env-arg).
• The user is debugging why sbx env create/run is asking for approval, or why a file, kit, or secret it declares was skipped or flagged.

Do not use this skill when

Do not use this skill when:

• The task is the underlying sbx create/run/rm flag-based workflow with no sbxenv.yaml file involved, use docker-sandboxes-lifecycle.
• The task is choosing network policy or storing a secret/registry credential independent of any environment file, use docker-sandboxes-network-credentials (this skill's secrets:/ registries:/bindings: blocks provision into that same store, but do not redefine its rules here).
• The task is authoring the kit spec.yaml a kits: entry points at, use docker-sandboxes-kits.

Core guidance

File resolution and required fields