代理執行基礎設施
Docker Sandboxes 0.42 將代理工作區移至雲端，並顯式規劃主機側副作用
Docker Sandboxes 0.42.0 讓同一套 `sbx` CLI 管理本機與雲端代理沙箱，支援檔案搬移、SSH、公開 HTTPS 服務及獨立網路政策。新版同時強化 `sbxenv.yaml` 的變更預覽與確認流程，但包含連接埠預設值及環境檔語意的相容性變更。
Docker 9 月 7 日發布 Sandboxes 0.42.0，核心新增 `sbx --cloud`：開發者可用與本機相近的命令，在 Docker 管理的雲端基礎設施啟動 AI 編碼代理，再透過 `sbx --cloud cp` 傳送檔案、以 SSH 連線，或把沙箱服務發布成 HTTPS 網址。本機與雲端沙箱各自保存運算資源、憑證及網路政策，亦可用 `sbx move` 搬移檔案系統；這不是透明的同一安全域，模型推論費用也仍由模型供應商另行計算。
更值得維運團隊注意的是環境檔行為。`sbx env` 會先列出 `sbxenv.yaml` 將在主機上改動的生命週期命令、憑證綁定、MCP 伺服器、工作區、kit、連接埠與沙箱資源，套用前要求確認；除非設定 `env.rememberHostCommands`，每次執行主機命令還會再次詢問。環境檔會以唯讀方式掛入其描述的沙箱，參數改用 `args` 區塊及 `--env-arg` 傳入，不再展開一般 `${VAR}`。若未聲明 `workspace`，現在不會暗中掛載環境檔所在目錄，必須明寫 `workspace: .`。
0.42.0 亦修補沙箱程序可誘使 daemon 開啟主機 D-Bus transport 執行命令，以及惡意沙箱搶占 OAuth callback port 的問題；官方未公布 CVE 編號或受影響版本範圍。升級另有破壞性改動：發布連接埠由雙棧 `tcp` 改成 `tcp4`，依賴 IPv6 loopback 的流程須明確指定協定。由於雲端沙箱涉及另外計費，且宣告式環境仍可要求執行主機命令，團隊應先在 CI 驗證 plan、網路政策、密鑰綁定與 teardown，再把它當成可重現的代理執行層。