Highlights
SSH access to sandboxes (experimental). Docker Sandboxes can now be used as SSH targets. After enabling SSH access, run sbx setup ssh once, then connect to an existing sandbox by name with ssh my-sandbox.sbx. Use the connection for interactive shells, one-shot commands, and SSH-based remote development.
What's New
SSH
sbx setup sshadds a managed*.sbxentry to your SSH config, making existing sandboxes available at<name>.sbx.- SSH connections start the local Docker Sandboxes daemon and the target sandbox automatically when needed.
- Connect using OpenSSH-compatible clients and remote-development tools such as VS Code, Cursor, Claude Desktop, and ChatGPT.
CLI
sbx createandsbx runaccept-p/--publishto publish sandbox ports at creation time.
Networking & Policy
DOCKER_SANDBOXES_PROXY=systemroutes sandbox egress through the host operating system's proxy configuration (macOS/Windows), including any PAC auto-config URL.- Governance-policy denials can now display an organization-configured support message (for example, who to contact).
Security & Audit
- Audit now emits execution-outcome records for network egress (per allowed connection) and filesystem mounts (per allowed path) — success, latency, and error class — alongside the policy-attributed decision records.
- sandboxd excludes itself from Windows Error Reporting so daemon crash dumps cannot capture in-memory credentials.
Performance
sbx secret lsand sandbox startup are faster on Linux hosts without an OS keychain — stored secrets are no longer all decrypted just to list or resolve credentials.
Bug Fixes
- Fixed sandboxd failing to start on Linux hosts without an OS keychain, where the on-disk secret store's key derivation could peg a CPU during startup and the CLI would kill the still-starting daemon.
- Fixed an intermittent "failed to fully delete sandbox" error when removing a running sandbox, caused by a network-teardown race with the engine's endpoint cleanup.