Docker Sandboxes
サポートされているエージェント

このガイドでは、サンドボックス環境での Cursor の認証、構成、および使用方法について説明します。

クイックスタート

プロジェクト ディレクトリ用にサンドボックスを作成し、Cursor を実行します:

$ sbx run cursor ~/my-project

ワークスペース パラメーターは省略可能で、デフォルトで現在のディレクトリになります:

$ cd ~/my-project
$ sbx run cursor

認証

Cursor は、API キーまたは OAuth の 2 つの認証方法をサポートしています。

API キー: 保存されたシークレットを使用して Cursor API キーを保存します。

$ sbx secret set -g cursor

あるいは、サンドボックスを実行する前にシェルで CURSOR_API_KEY 環境変数をエクスポートすることもできます。両方の方法の詳細については、Credentials (資格情報) (英語) を参照してください。

OAuth: API キーが設定されていない場合、Cursor は初回実行時にサインインを対話的に求めます。プロキシが api2.cursor.sh/auth/poll とのトークン交換を傍受するため、資格情報はホストによって管理され、サンドボックス内には保存されません。

構成

サンドボックスは、~/.cursor などのホストからのユーザーレベルの構成を取得しません。サンドボックス内では、作業ディレクトリ内のプロジェクトレベルの構成のみが利用可能です。回避策については、サンドボックスがユーザーレベルのエージェント構成を使用しないのはなぜですか？ (英語) を参照してください。

Cursor は、エージェント固有の指示についてワークスペースから AGENTS.md を読み取ります。

デフォルトの起動コマンド

追加の引数なしの場合、サンドボックスは以下を実行します:

cursor-agent --yolo

-- 以降の引数は、追加されるのではなく、これらのデフォルト値を置き換えます。--yolo を維持するには、ご自身で含める必要があります:

$ sbx run cursor -- --yolo -p "refactor this"

ベース イメージ

テンプレート: docker/sandbox-templates:cursor-agent-docker

リクエストがホスト プロキシを経由するように、エージェント トラフィック用に HTTP/1.1 および Server-Sent Events が事前に構成されています。認証状態はサンドボックスの再起動をまたいで保持されます。

ツールを事前インストールしたり、この環境をカスタマイズしたりするには、Customize (カスタマイズ) (英語) を参照してください。

このガイドでは、サンドボックス環境での GitHub Copilot の認証、構成、および使用方法について説明します。

クイックスタート

プロジェクト ディレクトリ用にサンドボックスを作成し、Copilot を実行します:

$ sbx run copilot ~/my-project

ワークスペース パラメーターは省略可能で、デフォルトで現在のディレクトリになります:

$ cd ~/my-project
$ sbx run copilot

認証

Copilot には、Copilot アクセス権を持つ GitHub トークンが必要です。保存されたシークレットを使用してトークンを保存します。

$ echo "$(gh auth token)" | sbx secret set -g github

あるいは、サンドボックスを実行する前にシェルで GH_TOKEN または GITHUB_TOKEN 環境変数をエクスポートすることもできます。両方の方法の詳細については、Credentials (資格情報) (英語) を参照してください。

構成

サンドボックスはホストからユーザーレベルの構成を取得しません。サンドボックス内では、作業ディレクトリ内のプロジェクトレベルの構成のみが利用可能です。回避策については、サンドボックスがユーザーレベルのエージェント構成を使用しないのはなぜですか？ (英語) を参照してください。

Copilot はデフォルトでワークスペース ディレクトリを信頼するように構成されているため、ワークスペース ファイルに対して確認を繰り返すことなく動作します。

デフォルトの起動コマンド

追加の引数なしの場合、サンドボックスは以下を実行します:

copilot --yolo

-- 以降の引数は、追加されるのではなく、これらのデフォルト値を置き換えます。--yolo を維持するには、ご自身で含める必要があります:

$ sbx run copilot -- --yolo -p "review this PR"

ベース イメージ

テンプレート: docker/sandbox-templates:copilot

ワークスペース ディレクトリを信頼するように事前に構成されています。

ツールを事前インストールしたり、この環境をカスタマイズしたりするには、Customize (カスタマイズ) (英語) を参照してください。

このガイドでは、サンドボックス環境での Google Gemini の認証、構成、および使用方法について説明します。

クイックスタート

プロジェクト ディレクトリ用にサンドボックスを作成し、Gemini を実行します:

$ sbx run gemini ~/my-project

ワークスペース パラメーターは省略可能で、デフォルトで現在のディレクトリになります:

$ cd ~/my-project
$ sbx run gemini

認証

Gemini には、Google API キーまたは Gemini アクセス権を持つ Google アカウントが必要です。

API キー: 保存されたシークレットを使用してキーを保存します。

$ sbx secret set -g google

あるいは、サンドボックスを実行する前にシェルで GEMINI_API_KEY または GOOGLE_API_KEY 環境変数をエクスポートすることもできます。両方の方法の詳細については、Credentials (資格情報) (英語) を参照してください。

Google アカウント: API キーが設定されていない場合、Gemini は起動時に対話的にサインインするように求めてきます。対話型認証はサンドボックスにスコープされており、サンドボックスを削除して再作成した場合は保持されません。

構成

サンドボックスは、~/.gemini などのホストからのユーザーレベルの構成を取得しません。サンドボックス内では、作業ディレクトリ内のプロジェクトレベルの構成のみが利用可能です。回避策については、サンドボックスがユーザーレベルのエージェント構成を使用しないのはなぜですか？ (英語) を参照してください。

サンドボックスは、Gemini に組み込まれた sandbox ツールを無効にします (サンドボックス自体が隔離を提供するため)。

デフォルトの起動コマンド

追加の引数なしの場合、サンドボックスは以下を実行します:

gemini --yolo

-- 以降の引数は、追加されるのではなく、これらのデフォルト値を置き換えます。--yolo を維持するには、ご自身で含める必要があります:

$ sbx run gemini -- --yolo -p "explain this"

ベース イメージ

テンプレート: docker/sandbox-templates:gemini

Gemini は組み込みの OAuth フローを無効にするように構成されています。認証はプロキシを介して API キーで管理されます。

ツールを事前インストールしたり、この環境をカスタマイズしたりするには、Customize (カスタマイズ) (英語) を参照してください。

クイックスタート

プロジェクト ディレクトリ用にサンドボックスを作成し、Docker Agent を実行します:

$ sbx run docker-agent ~/my-project

ワークスペース パラメーターはデフォルトで現在のディレクトリになるため、プロジェクトのディレクトリ内から sbx run docker-agent を実行することもできます。

認証

Docker Agent は複数のプロバイダーをサポートしています。使用したいプロバイダーのキーを保存されたシークレットで保存します。

$ sbx secret set -g openai
$ sbx secret set -g anthropic
$ sbx secret set -g google
$ sbx secret set -g xai
$ sbx secret set -g nebius
$ sbx secret set -g mistral

使用したいプロバイダーのみを設定する必要があります。Docker Agent は利用可能な資格情報を検出し、リクエストを適切なプロバイダーにルーティングします。

あるいは、サンドボックスを実行する前にシェルで環境変数 (OPENAI_API_KEY、ANTHROPIC_API_KEY、GOOGLE_API_KEY、XAI_API_KEY、NEBIUS_API_KEY、MISTRAL_API_KEY) をエクスポートすることもできます。両方の方法の詳細については、Credentials (資格情報) (英語) を参照してください。

構成

サンドボックスはホストからユーザーレベルの構成を取得しません。サンドボックス内では、作業ディレクトリ内のプロジェクトレベルの構成のみが利用可能です。回避策については、サンドボックスがユーザーレベルのエージェント構成を使用しないのはなぜですか？ (英語) を参照してください。

デフォルトの起動コマンド

追加の引数なしの場合、サンドボックスは以下を実行します:

docker-agent run --yolo

-- 以降の引数は、追加されるのではなく、これらのデフォルト値を置き換えます。run --yolo を維持するには、ご自身で含める必要があります:

$ sbx run docker-agent -- run --yolo agent.yml

ベース イメージ

サンドボックスは docker/sandbox-templates:docker-agent を使用します。このベースの上に独自のイメージを構築するには、Templates (テンプレート) (英語) を参照してください。

このガイドでは、サンドボックス環境での OpenAI Codex の認証、構成、および使用方法について説明します。

クイックスタート

プロジェクト ディレクトリ用にサンドボックスを作成し、Codex を実行します:

$ sbx run codex ~/my-project

ワークスペース パラメーターは省略可能で、デフォルトで現在のディレクトリになります:

$ cd ~/my-project
$ sbx run codex

認証

Codex は OpenAI の API キーを使用します。

API キー: サンドボックス環境を開始する前に、ホストマシンで API キーを保存されたシークレットとして設定します。

$ sbx secret set -g openai

あるいは、サンドボックスを実行する前にシェルで OPENAI_API_KEY 環境変数をエクスポートすることもできます。

OAuth: API キーを使用しない場合は、ホストで次のように OAuth フローを開始します:

$ sbx secret set -g openai --oauth

これにより、認証用のブラウザ ウィンドウが開き、結果のトークンが OS のキーチェーンに保存されます。OAuth フローはサンドボックス内ではなくホスト上で実行されるため、ブラウザ ベースの認証は追加の設定なしで機能します。

詳細については、Credentials (資格情報) (英語) を参照してください。

構成

サンドボックスは、~/.codex などのホストからのユーザーレベルの構成を取得しません。サンドボックス内では、作業ディレクトリ内のプロジェクトレベルの構成のみが利用可能です。回避策については、サンドボックスがユーザーレベルのエージェント構成を使用しないのはなぜですか？ (英語) を参照してください。

デフォルトの起動コマンド

追加の引数なしの場合、サンドボックスは以下を実行します:

codex --dangerously-bypass-approvals-and-sandbox

-- 以降の引数は、追加されるのではなく、これらのデフォルト値を置き換えます。フラグを維持するには、ご自身で含める必要があります:

$ sbx run codex -- --dangerously-bypass-approvals-and-sandbox "fix the build"

ベース イメージ

テンプレート: docker/sandbox-templates:codex

ツールを事前インストールしたり、この環境をカスタマイズしたりするには、Customize (カスタマイズ) (英語) を参照してください。