代理執行基礎設施
Docker Sandboxes 0.42 Moves Agent Workspaces to the Cloud and Explicitly Plans Host-Side Side Effects
Docker Sandboxes 0.42.0 lets the same `sbx` CLI manage local and cloud agent sandboxes, with support for file transfers, SSH, public HTTPS services, and separate network policies. The release also strengthens the change-preview and confirmation flow for `sbxenv.yaml`, but includes compatibility changes to port defaults and environment-file semantics.
Docker released Sandboxes 0.42.0 on September 7, with `sbx --cloud` as its headline addition. Developers can use commands similar to those for local environments to launch AI coding agents on Docker-managed cloud infrastructure, then transfer files with `sbx --cloud cp`, connect over SSH, or publish sandbox services at HTTPS URLs. Local and cloud sandboxes maintain separate compute resources, credentials, and network policies, while `sbx move` can be used to move filesystems between them. They do not transparently share a single security domain, and model inference charges continue to be billed separately by the model provider.
The environment-file behavior deserves particular attention from operations teams. `sbx env` first lists the lifecycle commands, credential bindings, MCP servers, workspaces, kits, ports, and sandbox resources that `sbxenv.yaml` will modify on the host, then requires confirmation before applying the changes. Unless `env.rememberHostCommands` is configured, it also prompts again each time a host command runs. The environment file is mounted read-only into the sandbox it describes. Parameters are now passed through an `args` block and `--env-arg`, and ordinary `${VAR}` expressions are no longer expanded. If `workspace` is not declared, the directory containing the environment file is no longer mounted implicitly; `workspace: .` must be specified explicitly.
Version 0.42.0 also fixes issues that allowed a sandbox process to induce the daemon to open a host D-Bus transport and execute commands, and enabled a malicious sandbox to seize the OAuth callback port. Docker has not published CVE identifiers or the range of affected versions. The upgrade includes another breaking change: published ports now default to `tcp4` instead of dual-stack `tcp`, so workflows that depend on the IPv6 loopback interface must specify the protocol explicitly. Because cloud sandboxes incur separate charges and declarative environments can still request the execution of host commands, teams should validate the plan, network policies, secret bindings, and teardown process in CI before treating the feature as a reproducible agent execution layer.