sbx-agent

Register Model Context Protocol servers on the host with sbx mcp and expose them to sandboxes through the built-in MCP gateway — registration, OAuth, static vs dynamic mode, and Cedar MCP policy. Use when adding an MCP server to a sandbox, deciding between --static-mcp and dynamic discovery, wiring OAuth credentials for a remote server, or writing a governance policy for MCP tool calls.

Run and operate Docker Sandboxes — choosing an agent, passing it flags, git workspace modes, ports, secrets, network policy, and sharing host skills into a sandbox. Use when starting or re-attaching to a sandbox, picking between the built-in agents, signing in from CI, copying files in or out, or reaching for the right sbx command.

Administer Docker Sandbox governance — local versus organization policy, filesystem and network access rules, audit logging, and sign-in enforcement across a fleet of developer machines. Use when creating or scoping an organization policy, diagnosing why an allow rule has no effect, writing filesystem mount rules, configuring audit delivery or SIEM forwarding, or deploying MDM sign-in enforcement. This is the administrator's view; route a single developer's blocked request to diagnosing-sbx-sandboxes instead.

Locate the official Docker Sandboxes page behind a claim, build or refresh the local mirror of the docs, and carry what changed upstream into the other sbx skills. Use when checking whether an sbx claim still holds, when `references/docs/` is missing, when an sbx release lands, or when a skill's verification date needs moving.

Work out why a Docker Sandbox cannot reach a host, install a package, keep a file, or start at all. Use when a download or clone fails inside sbx, a credential is rejected, a sandbox is killed or stops on its own, or something written inside it disappeared.

Build a Docker Sandbox template image by extending docker/sandbox-templates. Use when writing a Dockerfile for sbx, choosing a base variant, building a family of templates with bake, or publishing and loading one with sbx template.

Write a Docker Sandbox kit — a spec.yaml declaring setup steps, network permissions and credentials. Use when authoring or fixing a kit, choosing between kind mixin and kind sandbox, migrating a spec from schemaVersion 1 to 2, or a kit fails sbx kit validate.

Point an external editor or app — VS Code, Cursor, Claude Desktop, or ChatGPT — at a running Docker Sandbox over SSH via the `<name>.sbx` hostname, so the tool's UI stays on the host while files and processes run inside the sandbox. Use when setting up `sbx setup ssh`, wiring a remote-SSH connection in one of those apps, hitting a stalled or looping connection, or deciding whether Claude Desktop's credential-isolation warning applies to a given setup.