Docker Sandboxes 0.42、エージェントのワークスペースをクラウドへ移行し、ホスト側の副作用を明示的に計画

Dockerは9月7日、Sandboxes 0.42.0をリリースした。中核となる新機能は`sbx --cloud`だ。開発者はローカル環境とほぼ同じコマンドを使い、Dockerが管理するクラウドインフラストラクチャ上でAIコーディングエージェントを起動できる。その後、`sbx --cloud cp`でファイルを転送したり、SSHで接続したり、サンドボックスのサービスをHTTPS URLとして公開したりできる。ローカルとクラウドのサンドボックスは、それぞれ個別にコンピューティングリソース、認証情報、ネットワークポリシーを保持する。`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を検証すべきだ。