Docker sbxとは？Sandboxes導入と使い方

Docker Sandboxes (sbx) とは？結論と Dev Containers との関係

sbx は AI エージェント用の microVM を立てる Docker の CLI

Docker Sandboxes は、Claude Code や Codex などの AI コーディングエージェントを、手元のマシン上の隔離された microVM で動かすための Docker の製品です。操作は sbx という単体の CLI で行い、Docker Desktop や Docker Engine は要りません。サンドボックスごとに専用の Linux カーネル・Docker デーモン・ファイルシステム・ネットワークを持つので、エージェントがパッケージを入れたりコンテナをビルドしたりしても、ホストには残りません（Docker Sandboxes 公式 docs）。

sbx CLI とローカルのサンドボックスは商用利用も含めて無料で、クラウド上のサンドボックスは従量課金、組織全体へポリシーを強制する機能は別の有料サブスクリプションです（FAQ）。本記事はローカルのサンドボックスを対象に、2026 年 11 月時点の公式 docs で確かめた手順で書いています。

エージェントに自律実行を任せるときの課題

エージェントを業務で使うと、コマンドの自律実行やコンテナビルドをどこまで許すかで必ず迷います。自由度を上げるほど、ローカル環境の破壊や、~/.aws・~/.ssh のような機微ファイルの漏洩が起こりうるからです。

これまでの定番は Dev Containers でした。ただ実際の現場では、エージェントにコンテナを扱わせるために /var/run/docker.sock をマウントする構成が多く、ホストの Docker デーモンへ root 相当で触れる口を自分で開けている状態になりがちでした。

【結論】乗り換える価値と「隔離の線引き」

先に結論をまとめます。

• 隔離の境界が microVM まで上がります。 サンドボックス内に専用の Docker デーモンがあるので、docker.sock をマウントする必要がなくなり、ワークスペースの外にある機微ファイルも見えません。
• シークレットをエージェントから隠せます。 sbx secret set で保存したキーはホストに残り、VM 内にはダミー値だけが入ります。送信時にホスト側のプロキシが実値へ差し替えます。
• ただし差し替えが効くのは HTTP リクエストヘッダに載る認証だけです。 AWS SigV4 のような署名型の認証は、この仕組みに乗りません。
• チームで「揃える」のは無料、「守らせる」のは有料です。 Kit や環境ファイル（sbxenv.yaml）で設定は配れますが、ルールを強制できるのは組織ポリシーだけです。
• 守るのはホストで、リポジトリではありません。 既定ではワークスペースが読み書きで直接マウントされるため、エージェントによるコードの破壊や不正なコミットは Git 側で防ぐ必要があります。

以下、導入の最小手順から始めて、Dev Containers との違い、sbx secret・sbx policy・sbx kit の使い方、残る制約の順に見ていきます。

sbx install から sbx run までの最小手順

動作要件とインストール

インストール手順は OS ごとに分かれています（Install Docker Sandboxes）。

• macOS: macOS Sonoma 14 以降・Apple silicon。Homebrew で入れます。
• Windows: Windows 11・64 bit の Intel / AMD。ローカルのサンドボックスには Windows Hypervisor Platform の有効化が要ります。
• Linux: Ubuntu 24.04 以降。ローカルのサンドボックスには KVM が有効で、自分のユーザーが kvm グループに入っている必要があります。Linux Mint や Pop!_OS などの派生ディストリビューションは Docker のテスト・サポート対象外です。

# macOS
brew trust docker/tap
brew install docker/tap/sbx

# Windows（現在のユーザーに入れる）
winget install -h Docker.sbx

# Ubuntu（Docker Engine を入れずに sbx だけ入れる）
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt install docker-sbx

# Linux で KVM が使えるかの確認と、kvm グループへの追加
lsmod | grep kvm
sudo usermod -aG kvm $USER

Ubuntu では curl -fsSL https://get.docker.com | sudo SBX=1 sh で Docker Engine と docker-sbx パッケージをまとめて入れることもできます。仮想マシンや VDI の中で動かす場合は、入れ子の仮想化が使える環境でないとローカルのサンドボックスは起動しません。パッケージ・アーカイブからの手動インストールは docker/sbx-releases の README にあります。

sbx login と最初の sbx run

インストールしたら Docker アカウントでサインインし、プロジェクトのディレクトリでエージェントを起動します（Get started）。

sbx login                       # ブラウザで Docker の OAuth が開く
cd ~/my-project
sbx run --name my-sandbox claude

初回はエージェントのイメージを取得するため時間がかかり、2 回目以降はキャッシュから数秒で立ち上がります。別のターミナルで sbx ls を叩くと、サンドボックス名・エージェント・状態・公開ポート・ワークスペースが一覧で出ます。サンドボックスはエージェントを終了しても残るので、sbx stop my-sandbox で止め、不要になったら sbx rm my-sandbox で消します。消すと中に入れたパッケージやイメージもまとめて消え、ホスト側の作業ツリーはそのまま残ります。

引数なしで sbx を実行すると、全サンドボックスの状態・CPU・メモリを並べたダッシュボードが開きます。ここからエージェントへの attach（Enter）、シェル起動（x）、停止・削除ができ、tab で切り替えるネットワークのパネルでは接続ログを見ながら宛先を許可・拒否できます（Usage）。

ネットワークの初期プリセット（sbx policy init）

初めての sbx run で、対話ターミナルならネットワークポリシーのプリセットを聞かれます。対話なしで決めておくなら、sbx run の前に sbx policy init を実行します（sbx policy init）。

sbx policy init balanced    # 公式が推奨する選択

初期化は一度だけの操作で、やり直すときは sbx policy reset で全ルールを消してから選び直します。迷ったら Balanced から始め、必要な宛先を足していく形が無難です。

版の確認と更新

入っている版は sbx version で確かめられ、--debug を付けるとデーモンとビルドの詳細も出ます（sbx version）。Kit の v3 形式は v0.45 以降、ChatGPT・Claude Desktop からの自動接続は v0.48.0 以降が前提なので、機能が見当たらないときはまず版を見てください。

更新は、導入に使ったパッケージマネージャ（Homebrew・WinGet・apt）の側で行います。2026 年 11 月時点の CLI リファレンスには sbx update というサブコマンドは載っていません。Windows でマシン全体に入れた場合は、他のユーザーのセッションで sbx デーモンが動いていると、更新に再起動が要ることがあります。

Dev Containers との違い：3 つの弱点をどう塞ぐか

microVM によるエージェント専用ランタイムの仕組み

Docker Sandboxes は、コンテナではなく microVM（ハイパーバイザによる隔離） の上でエージェントを動かすランタイムです。サンドボックスごとに専用の Linux カーネルを持ち、VM はその境界の外にあるホストのプロセスやファイルに触れません。エージェントは VM 内で sudo を持つ非 root ユーザーとして動き、隔離を担うのは VM 内の権限分離ではなくハイパーバイザの境界です（Sandbox isolation）。

この構造で、Dev Containers が抱えていた 3 つの弱点がどう変わるかを見ていきます。

弱点 1：カーネル共有と docker.sock マウント

Dev Containers はホストとカーネルを共有し、エージェントにコンテナ操作を許すには /var/run/docker.sock のバインドマウントがほぼ必須でした。sbx は VM の内側に専用の Docker Engine を持ち、エージェントからホストの Docker デーモンへの経路がありません。公式 docs も、ホストのソケットをマウントすればエージェントに環境全体へのアクセスを渡すことになると注意しています。エージェントは VM の中で自由にイメージをビルドし、コンテナを起動できます。

弱点 2：ホームディレクトリの露出

Dev Containers では、利便性のためにホームディレクトリごとマウントしたり、シンボリックリンク経由でホストの機密ファイルに届いてしまったりする事故が起こりがちでした。sbx がホストから共有するのはワークスペースだけで、既定ではホストと同じ絶対パスに見えます。ワークスペースの外を指すシンボリックリンクは辿りません（Architecture）。そのため ~/.aws や ~/.ssh が意図せず見える状態は起きません。

ひとつ例外として、公式 docs はハードリンクを挙げています。ワークスペース内にホストのファイルへのハードリンクがあると、エージェントはワークスペースのパス経由でその実体を読み書きできます。

弱点 3：コンテナ内に置いた API キー

Dev Containers では API キーを環境変数や設定ファイルとしてコンテナに置くため、エージェントから実値が見え、外へ持ち出される余地がありました。sbx は、キーをホストの OS キーストア（macOS の Keychain、Windows の Credential Manager、Linux の Secret Service）に保管し、VM には センチネル値（ダミー文字列） だけを渡します。外向きのリクエストがホスト側のプロキシを通るときに、プロキシがこれを実値へ差し替えます（Manage credentials）。

比較表：IDE 連携の手厚さは Dev Containers が上

隔離の強さでは sbx が上ですが、エディタとの一体感は Dev Containers に分があります。移行を検討するチームが最初に気にする点なので、表に並べます。

sbx secret set と資格情報プロキシの仕組み・適用限界

sbx secret set の使い方

モデルプロバイダの API キーなどは sbx secret set <サービス名> で保存します。値はその場の対話入力で受け取るので、コマンド履歴に残りません（sbx secret set）。

sbx secret set anthropic                          # 全サンドボックス共通（既定）
sbx secret set openai --sandbox my-sandbox        # 1 つのサンドボックスに限定
sbx secret set github --command 'gh auth token'   # ホストのコマンドの出力を値に使う
sbx secret set anthropic --ref 'op://Work/Anthropic/credential'  # 1Password の参照
sbx secret import                                 # シェルの環境変数から取り込む
sbx secret ls

運用で押さえる点は次のとおりです。

• スコープ: サービスのシークレットは既定で全サンドボックス共通です。--sandbox で個別に設定すると、そちらが優先されます。
• 反映: 追加・更新・削除は、既存のローカルサンドボックスにも再起動なしで効きます（--command / --ref の場合も同じ）。
• 優先順位: 同じサービスに複数の値の出どころがあるときは、保存したシークレットが優先されます。
• 動的な取得: --ref は 1Password の op:// 参照と AWS Secrets Manager の ARN に対応し、ホストに op か aws の CLI が入って認証済みである必要があります。取得した値は既定で 55 分キャッシュされ、--refresh 30m や --refresh on-demand で変えられます。
• 保存先: Linux でデスクトップのキーリングが動いていない環境（ヘッドレスのサーバーなど）では、~/.config/com.docker.sandboxes の下に権限 0700 のファイルとして保存されます。このディレクトリを読めるユーザーやプロセスは値を取り出せるので、扱いには注意が要ります。

サービス名は anthropic・openai・github・google などが組み込みで、それぞれ環境変数名と、プロキシが値を差し込む API ドメインが決まっています。Codex なら sbx secret set openai --oauth でホスト側のブラウザから OAuth を済ませることもできます（Codex）。

センチネル置換方式（sbx secret set-custom）

組み込みのサービスに当てはまらない API には sbx secret set-custom を使います。こちらは公式 docs で実験的機能とされ、フラグやダミー値の形式が予告なく変わる可能性があります。

printf '%s' "$API_KEY" | sbx secret set-custom \
    --host api.example.com \
    --env API_KEY \
    --value-stdin

標準入力から渡すのは、--value に実値を書くとシェルの履歴とプロセスの引数に残るためです。設定すると、サンドボックス内の環境変数 API_KEY には sbx-cs-<ランダム文字列> の形のセンチネル値が入ります。サンドボックスから指定ホスト（ここでは api.example.com）へリクエストを送り、HTTP リクエストヘッダ にこの文字列が現れたときだけ、ホスト側のプロキシが実値に書き換えて送り出します。リクエストボディの中は置換されません。--host は繰り返し指定でき、*.example.com のようなワイルドカードも使えます。

「置換できない認証方式」への限界

この仕組みは、ヘッダに載った文字列を差し替える ことで成り立っています。裏返すと、キーそのものがヘッダに載らない認証方式には原理的に使えません。

代表例が署名型の認証です。署名型ではシークレットキーを送らず、リクエストの内容から署名を計算する鍵として使います。そのため次の 2 点が同時に起こります。

1. 置換する対象がない: キーがリクエストに現れないので、プロキシが差し替える文字列がありません。
2. 後から書き換えると署名が壊れる: 署名はヘッダやボディから計算済みなので、送信後に内容を変えれば検証は失敗します。

「エージェントにキーを見せない」という sbx の利点は、ベアラートークンのように認証情報をそのままヘッダへ載せる方式で成り立つ、と捉えるのが正確です。AWS の API で使われる AWS SigV4 はこの署名型にあたります。公式 docs に「SigV4 は非対応」とは書かれていませんが、上の理由から置換方式には乗らないと考えられます。

置換できない認証を扱う回避策（AWS SigV4 の場合）

署名型の認証を使う環境で sbx を使うなら、次のどれかを選ぶことになります（勧める順）。

A. Bedrock なら Bearer トークンを使う
用途が Amazon Bedrock 経由の LLM 呼び出しに限られるなら、SigV4 ではなく Bedrock の Bearer トークンで認証すれば、置換方式に乗せられます。キーを VM に入れない、という sbx の利点を保てるのはこの方法だけです。

B. VM 内に短命な STS 資格情報を入れる（現実的な落としどころ）
キーを VM に置かない、という理想は諦め、AWS STS で発行した短命な一時認証情報（AWS_ACCESS_KEY_ID・AWS_SECRET_ACCESS_KEY・AWS_SESSION_TOKEN）を実値として VM に渡します。長期キーを置いていた従来より被害範囲は狭く、有効期限と IAM の権限を絞れば影響を抑えられます。

C. ホスト側に SigV4 署名プロキシを立てる
awslabs/aws-sigv4-proxy のようなツールをホストで動かし、サンドボックスからは未署名のリクエストをそこへ送る方法です。サンドボックスからはホストのサービスへ host.docker.internal で届き、そのポートを sbx policy allow network localhost:<ポート> で許可する必要があります（Local services）。構成としては自前で組んで確かめる部分が多くなります。

sbx policy による送信先の絞り込み

sbx policy allow network の書き方

プリセットを決めたあとは、sbx policy allow network で宛先を足していきます（sbx policy allow network）。

sbx policy ls                                             # いま効いているルール
sbx policy allow network registry.npmjs.org               # 1 ホストを許可
sbx policy allow network "*.example.com,api.example.org:443"  # カンマ区切り・ポート指定
sbx policy allow network --sandbox my-sandbox api.example.com # 1 つのサンドボックスだけ
sbx policy log                                            # 送信と一致したルールの記録

• 宛先はホスト名・ドメイン・IP アドレス・CIDR をカンマ区切りで並べます。*.example.com は 1 階層、**.example.com は複数階層のサブドメインに一致し、"**" はすべての宛先の許可です。
• ルールは既定で全サンドボックスに効き、--sandbox を付けるとそのサンドボックスだけに効きます。
• 拒否は sbx policy deny、削除は sbx policy rm network --id <ルール ID> で行います。同じスコープに逆の判定のルールがあると追加は拒まれるので、先に古いルールを消します。スコープが違えば共存でき、その場合は拒否が勝ちます。
• 既定は TCP が対象です。--method を付けると、HTTP のメソッド・パス・クエリまで絞ったルールにできます。

Balanced と Locked Down では、どのルールにも当たらない送信はブロックされ、その場で承認を求められます（Local policy）。接続に失敗したときは、sbx policy log でどのルールに止められたかを見るのが最短の確認手順です。

Kit のルール・組織ポリシーとの関係

組織ポリシーが無い状態では、自分のルールと Kit のルールが合わさり、どれかが許可すれば通ります。Kit のルールはプリセットに関係なく、Locked Down でも効きます。どこから来たルールでも、拒否は許可に勝ちます。

有料の組織ポリシーが有効になると、許可を与えるのは組織の許可ルールだけになり、sbx policy で足したローカルの許可ルールは評価されなくなります。ローカルの拒否ルールはその上に引き続き効きます（FAQ）。開発者は自分の手元で絞ることはできても、組織の許可を超えて広げることはできません。

チームでの設定共有：sbx kit・sbxenv.yaml・組織ポリシー

sbx policy で足したルールは各自の手元の設定です。チームで同じ環境とルールを使うには、性質の違う 3 つの手段があります。

手段 A：Kit による道具と通信ルールの配布（無料）

Kit は、サンドボックスに入れるソフトウェアと設定をまとめたものです。中身を宣言する YAML（ディスクリプタ）と、ソフトウェアを入れる Dockerfile からなり、コンテナイメージとして公開して使います（Kits）。実は sbx run claude や sbx run codex の時点で、組み込みの Kit を使っています。

Kit には役割が 2 つあります。

複数の Kit を 1 つにまとめて公開する Kit セット も作れます。

Docker が勧めているのは v3 形式です（v3 は sbx v0.45 以降が必要で、v2 も引き続きサポートされています）。この記事の初版に載せた spec.yaml の抜粋は v3 の書式ではなかったため、v3 の書き方に改めました。社内 API を叩く CLI を mixin にするなら、ディスクリプタは次のような形です（Build a tool mixin）。

# company-cli/company-cli.yaml
# syntax=docker/sandbox-kit:3
schemaVersion: "3"
kind: mixin
displayName: Company CLI

capabilities:
  - type: com.docker.sandbox/network-policy@1
    config:
      runtime:
        allow:
          - api.example.com:443
  - type: com.docker.sandbox/credential@1
    config:
      service: company-api
      phase: runtime
      apiKey:
        name: COMPANY_API_KEY
        proxyManaged: true
        inject:
          - domain: api.example.com
            header: Authorization
            format: "Bearer %s"

CLI 本体は同じディレクトリの company-cli.dockerfile で入れます。ディスクリプタの capabilities が、サンドボックスを用意するときに Docker Sandboxes がすること（宛先の許可、ホストに保存した company-api のキーをヘッダへ差し込むこと）を表します。通信の許可と資格情報の利用は別の項目で、資格情報を宣言しただけではその宛先へは繋がりません。サンドボックス作成時や起動のたびに走らせたい処理は、lifecycle の capability（install / startup のフック）で書きます（Author kits）。

sbx secret set company-api                       # キーをホストに保存
sbx run claude --name tools-test --kit ./company-cli   # ローカルのディレクトリから試す

# 公開（Buildx でイメージとして push）
docker buildx build ./company-cli -f ./company-cli/company-cli.yaml \
    -t docker.io/<NAMESPACE>/company-cli:1.0.0 --push

起動時に Kit の資格情報の利用を承認するよう求められます。保存と承認は別の手順で、保存しただけでは他人が作った Kit にキーは渡りません。Kit はイメージのほか、git+https://github.com/<ORG>/<REPO>.git#ref=<COMMIT>&dir=company-cli の形で Git のソースのまま共有することもでき、その場合は sbx がサンドボックス作成時にビルドします（Build and distribute kits）。

sbx kit のサブコマンドは実験的機能で、v3 での役割は次のように分かれます。

Kit を使うかどうかは、起動する開発者が --kit を付けるかに任されます。リポジトリで配れても、使うことを強制する力はありません。

手段 B：sbxenv.yaml による構成の宣言（実験的機能）

Kit がツールとその要件を包むのに対し、環境ファイル sbxenv.yaml は、どの Kit を選び、どのワークスペース・ポート・環境変数・資格情報・起動時のコマンドで動かすかを宣言します。devcontainer.json に最も近い位置づけです（Sandbox environment files）。

# web-app-env/sbxenv.yaml（プロジェクトの外、隣に置く）
schemaVersion: "1"
name: web-app
agent: claude
workspace: ./web-app

kits:
  - docker.io/<NAMESPACE>/company-cli:1.0.0

env:
  NODE_ENV: development

ports:
  - sandbox: 3000
    host: 3000

web-app-env で sbx env run を実行すると、変更内容（plan）が表示され、承認するとサンドボックスを作って attach します。sbx env plan（確認だけ）・sbx env create・sbx env exec・sbx env rm もあり、各自の共通設定はホームの ~/.sbxenv.yaml に置けます。

置き場所には注意が要ります。環境ファイルにはホスト上で走る lifecycle・シークレット・MCP のコマンドを書けるため、公式 docs はファイルを 書き込み可能なマウントの外 に置くよう求めています。エージェントが書き換えると、次回の実行でホストに走るコマンドが変わってしまうからです。ワークスペースに置く場合はワークスペースの直下に置けば、既定で読み取り専用でマウントされます。sbx env はコマンドもファイル形式も変わりうる実験的機能なので、チームの共有基盤として据えるのは様子を見てからが無難です。

手段 C：組織ポリシーによる強制（有料）

ルールを守らせるには、有料の 組織ガバナンス（AI Governance） を使います。管理者は Docker Home か AI Governance API から、ネットワーク（どの宛先に届くか）・ファイルシステム（どのホストのパスをマウントできるか）・MCP（どの MCP サーバーを登録・利用できるか）のポリシーを組織単位で決めます（Organization governance）。有効になると組織の許可ルールだけが許可を与え、ローカルや Kit の許可ルールは効かなくなります。

整理すると、チームで「揃える」のは Kit（安定・無料）か sbxenv.yaml（実験的・より広い範囲）、「守らせる」のは組織ポリシー（有料）です。三者は排他ではなく、組織ポリシーで下限を敷き、日々の環境定義を Kit や環境ファイルで配る形が素直な運用です。

ベースイメージとテンプレートの選び方

組み込みのエージェント名（claude・codex など）は、Docker Hub の Debian ベースの Kit docker.io/sbx/<名前>:latest を指します。エージェントの版を固定したいときは、docker.io/docker/sbx-kit-claude:<版> のような版付きの workload を指定します（Use kits）。

従来の docker/sandbox-templates:<種類>（claude-code・codex など）は、Ubuntu ベースの旧来のイメージという位置づけになりました。多くの種類に Git・Docker CLI・Node.js・Python・Go・Java が入っています（Base images）。独自の workload を作るときは Dockerfile の FROM でこれらを土台にします。手で整えたサンドボックスは sbx template save my-sandbox my-template:v1 で保存し、sbx run -t my-template:v1 claude で再利用できます。ただし保存したテンプレートには、手で置いた API キーもそのまま入る点に注意してください。

開発サーバー・エディタ・MCP・他のエージェントの使い方

Dev Containers から移るときに一番気になるのは、版を揃えた環境で開発サーバーを動かし、ホストのブラウザやエディタから触る日々の流れが保てるかどうかです。保てますが、操作の入口が変わります。

開発サーバーを起動する 3 つの経路

1. エージェントに任せる: サンドボックス内のエージェントが npm run dev を実行します。VM の中で完結するので、ホストは汚れません。
2. sbx exec で人が叩く: sbx exec -it my-sandbox bash で対話シェルに入れます。sbx exec はフォアグラウンド専用で、-d によるバックグラウンド実行には対応していません。セッションを閉じてもサンドボックスごと動かし続けたいときは、sbx run -d --name my-project claude . で detached モードにします。
3. Kit に宣言する: Kit の lifecycle の startup フックはサンドボックスの起動のたびにエージェントと並んで走ります。セッションが切れても止めたくないなら、long-running@1 の capability を宣言します（Author kits）。

ポート公開の明示

起動しただけでは、ホストからは届きません。ポートの対応は別に指定します（Usage）。

sbx run --publish 8080:3000 --name my-sandbox claude   # 作成時に指定
sbx ports my-sandbox --publish 8080:3000               # 既存のサンドボックスに後から追加
sbx ports my-sandbox --publish 3000                    # ホスト側のポートは OS に任せる
sbx ports my-sandbox --unpublish 8080:3000

これでホストの localhost:8080 がサンドボックスの 3000 番に繋がります。ここで サンドボックス内のサーバーは 0.0.0.0（IPv6 も含めるなら [::]）で待ち受ける必要があります。多くの開発サーバーは既定で 127.0.0.1 だけを listen するので、--host 0.0.0.0 に当たるオプションを付けないとホストから見えません。既存のサンドボックスに sbx run で入り直したときは --publish が無視されるので、sbx ports を使います。Dev Containers の自動ポート転送に慣れているほど、最初につまずきやすい箇所です。

sbx setup ssh によるエディタ接続

VS Code や Cursor から中を触るときは、最初に一度 sbx setup ssh を実行し、以降は ssh <サンドボックス名>.sbx で接続します（Editor and app integrations）。

sbx setup ssh                    # ~/.ssh/config に管理ブロックを書き込む
sbx create --name demo shell .   # 接続先のサンドボックスを作っておく
ssh demo.sbx

接続には SSH 鍵もネットワークポートも使いません。ProxyCommand が sbx デーモンのローカルソケットへ中継し、Docker にログインしている間だけ接続が通ります。サンドボックス内で SSH サーバーは動いておらず、止まっているサンドボックスは接続時に起動します。

VS Code なら Remote - SSH 拡張で Remote-SSH: Connect to Host... を開き、demo.sbx を手で入力します。ワイルドカードの設定から個々のサンドボックス名は候補に出ないためです。接続後のフォルダ選択がホームの /home/agent から始まることがあるので、ワークスペースのパス（ホストと同じ絶対パス）を自分で選びます。macOS では VS Code の版によって再接続を繰り返すことがあり、公式 docs は remote.SSH.useLocalServer を false にする回避策を載せています（Connect VS Code）。Cursor・Claude Desktop・ChatGPT 向けの手順も同じページ群にあり、macOS と Windows では v0.48.0 以降の sbx setup ssh --auto-create で、ChatGPT と Claude Desktop に専用サンドボックスへの接続を足せます。

sbx mcp による MCP サーバーの受け渡し

ホストの ~/.claude にある MCP 設定やフックは、サンドボックスには引き継がれません。MCP サーバーは、ホスト側で sbx mcp に登録し、サンドボックスの MCP ゲートウェイ経由で渡します（MCP gateway）。

sbx mcp add notion --url https://mcp.notion.com/mcp     # OAuth が要るならここで認可
sbx mcp ls
sbx run claude --name my-session --static-mcp notion    # 起動時に読み込むサーバーを固定
sbx mcp load linear --sandbox my-session                # 稼働中のサンドボックスへ追加

--static-mcp を付けないと動的モードになり、エージェントが登録済みのサーバーを探して自分で繋ぎます。--static-mcp none ならサーバーなしで起動します。対応するエージェントは Claude Code・Codex・Devin・Gemini・Kiro・OpenCode です。OAuth のクライアントシークレットなどはホストの資格情報ストアに残り、サンドボックスには入りません。

Codex など他のエージェントでの実行

sbx run のエージェント名を差し替えれば、Claude Code 以外も同じ手順で動きます。ローカルで使えるのは Claude Code・Codex・Copilot・Cursor・Devin・Docker Agent・Droid・Gemini・Kiro・OpenCode と、エージェントなしの shell です（Supported agents）。

sbx secret set openai --oauth   # ホストのブラウザで認証（API キーなら --oauth なし）
cd ~/my-project
sbx run codex

Codex の既定の起動コマンドは codex --dangerously-bypass-approvals-and-sandbox で、承認の確認なしに動きます（Codex）。隔離を VM に任せる前提の設定なので、ワークスペースの中身は守られない点と合わせて判断してください。~/.codex のようなユーザー単位の設定も読み込まれず、作業ディレクトリ内のプロジェクト単位の設定だけが使われます。

導入前に押さえるべき残存リスク（隔離の境界線）

「ホスト」は守れても「リポジトリ」は対象外

sbx はホスト環境の保護には強力ですが、直接マウントしたワークスペースの中身は守りません。既定のモードではエージェントが作業ツリーを読み書きでき、書いた変更はその場でホストにも現れます。エージェントがコードを壊したり、誤ったコミットやプッシュをしたりすれば、そのままホストのリポジトリに残ります。

緩和策として、sbx run --clone claude . の clone モード があります。ホストのリポジトリは読み取り専用でマウントされ、エージェントはサンドボックス内の別のクローンで作業するので、ホストの .git や作業ツリーには手を出せません（Usage）。ただしサンドボックスを消すと中のクローンも消えるため、先に fetch か push しておく必要があります。どちらのモードでも、別ブランチでの作業やプッシュ制限といった Git 側の防御は Dev Containers の頃と変わらず必要です。

ワークスペース直下の .env 露出とリソース消費

同じ理由で、ワークスペースに置いた .env などはファイルシステムの隔離の外にあり、エージェントから読めます。clone モードでも .env は読めると公式 docs に明記されています。こうした値が外へ送られないよう、宛先は Balanced か Locked Down で絞り、必要なものだけ許可しておくのが前提になります。

また、サンドボックスごとに Docker デーモンの状態・イメージキャッシュ・パッケージを個別に持ち、サンドボックス間でイメージやレイヤは共有されません（Architecture）。ビルドやインストールを重ねるほどディスクの消費は増えるので、使い終わったサンドボックスは sbx rm で消す運用を決めておくと安心です。

まとめ：導入判断のためのチェックリスト

Docker Sandboxes (sbx) は、AI エージェントに自律実行の場を与えつつホストを守る、という目的では Dev Containers から乗り換える価値のある仕組みです。自チームで導入するかを決めるときは、次の判断軸を確かめてください。

隔離がどこまで効き、どこから先は自分たちで守るのか。その境界線を押さえておけば、エージェントの力を安全に引き出す開発環境を組み立てられます。